System design is not about memorising architecture diagrams. It is about making the right trade-offs.
When learning system design, it is tempting to start with:
“Should I use Kafka, Redis, Kubernetes, microservices or sharding?”
A better starting point is:
“What problem am I actually trying to solve?”
I like to look at system design through five key dimensions:
1️⃣ Scalability: Can we grow?
A system that works for 10K users may struggle at 10M.
Key considerations include:
• Horizontal scaling
• Load balancing
• Stateless services
• Caching
• Data partitioning
• Autoscaling
• Capacity planning
The important question is: What becomes the bottleneck as demand grows?
2️⃣ Throughput: How much can we process?
Some useful measures are:
RPS: Requests per second
TPS: Transactions per second
Concurrency: Simultaneous requests
Resource utilisation: CPU, memory, network
Caching, queues, asynchronous processing, batching and additional workers can improve throughput.
But first, find the bottleneck.
3️⃣ Availability: Can users access the system when they need it?
For critical systems, downtime matters.
99.99% availability still permits roughly 52 minutes of downtime per year.
60 ** 0.01% = 60/10000 = .006
Redundancy, replication, failover and eliminating single points of failure become essential.
Two important concepts:
RTO: How quickly must we recover?
RPO: How much data can we afford to lose?
4️⃣ Resilience: What happens when things fail?
Networks fail. Services timeout. Databases go down. Deployments fail.
Good systems are designed with this assumption.
Timeouts, retries with exponential backoff, circuit breakers, failure isolation, graceful degradation and observability help systems contain failures and recover.
5️⃣ Performance: How fast is the experience?
A system can be scalable and highly available, yet still feel slow.
Look at:
• P95/P99 latency
• Cache hit ratio
• Database performance
• Indexing
• CDNs
• Read replicas
• Efficient data access
Optimise the user-visible bottleneck, not simply the easiest metric to improve.
The bigger lesson:
➡️ These dimensions often compete.
➡️ Caching can improve latency but introduce consistency challenges.
➡️ Replication can improve availability but increase cost.
➡️ Async processing can improve throughput but add complexity.
➡️ Microservices can enable independent scaling but introduce distributed-system challenges.
There is no perfect architecture.
There is only an architecture that makes the right trade-offs for a given set of requirements.
My simple mental model:
Understand requirements → Define metrics → Find bottlenecks → Choose patterns → Design for failure → Measure → Iterate.
Good system design is not about knowing every technology.
It is about knowing why you are choosing one.