/5 min read
Every Developer Should Know System Design
System Design is not just for Architects. It is for every developer who is building scalable and maintainable applications for global audience.
B
Bikash JaiswalSenior AI Engineer
System Design is not just for Architects. It is for every developer who is building scalable and maintainable applications for global audience.
Distributed systems are systems that are spread out over a network. These networks of machines physical or virtually (nodes) are connected to each other and communicate with each other to perform tasks. The nodes can be Physical machines(e.g,, phone) or a software process (e.g., browser).
Why should we think about distributed systems while building applications?
We want our application to be available to users all the time and run in all possible devices like phone, tablet, desktop, etc. Best example of this is web.
We don't want our application to be down for long time. It must be free from single point of failure. It can only be achieved by distributing the application.
We don't want our application to be slow or unresponsive. It must be able to handle high traffic or workloads. It can only be achieved by when we reduce the load on a single machine and distribute it across multiple machines. For example, High traffic from all over the world to Google search engine can't be handled by single node. Thus, Google search engine is distributed across multiple nodes.
Understanding these core concepts will help you design systems that scale gracefully and handle failures elegantly.
At the heart of any distributed system lies inter-node communication. Nodes exchange messages over the network, but this seemingly simple task raises critical questions:
Client → Load Balancer → API Gateway → Service A → Message Queue → Service B
When nodes need to agree on something (leader election, distributed locks, transaction commits), you need consensus algorithms:
Real-world example: When you book a flight, multiple services must coordinate—inventory, payment, and booking confirmation must all succeed or all fail (distributed transaction).
Scalability is about handling growth—more users, more data, more requests—without degrading performance.
| Metric | Definition | Target |
|---|---|---|
| Throughput | Requests processed per second | Maximize |
| Latency | Time to process a single request | Minimize (p50, p95, p99) |
| Capacity | Maximum load before degradation | Plan for 2-3x peak |
Scaling Strategies:
A resilient system continues operating even when components fail. Failures are inevitable—plan for them.
Availability in "Nines":
| Availability | Downtime/Year | Downtime/Month |
|---|---|---|
| 99% (two 9s) | 3.65 days | 7.3 hours |
| 99.9% (three 9s) | 8.76 hours | 43.8 minutes |
| 99.99% (four 9s) | 52.6 minutes | 4.38 minutes |
| 99.999% (five 9s) | 5.26 minutes | 26.3 seconds |
Techniques for High Availability:
You can't fix what you can't see. Observability is the ability to understand your system's internal state from its external outputs.
The Three Pillars:
Operational Excellence:
In distributed systems, consistency defines how and when updates become visible across nodes.
| Model | Description | Use Case |
|---|---|---|
| Strong Consistency | All nodes see the same data at the same time | Banking, inventory |
| Eventual Consistency | Updates propagate eventually; temporary inconsistency allowed | Social media feeds, DNS |
| Causal Consistency | Related operations maintain order | Collaborative editing |
Key Concepts:
System design is a fundamental skill for anyone building software that serves real users.