Distributed System Architecture

Why architecture matters

Imagine building a city: the same homes, roads, and power lines can produce either smooth traffic or daily chaos depending on the layout. Distributed systems work the same way. Architecture is the high-level structure of how services, data, and communication are organized.

Common styles include:

• Client-server: many clients talk to a central service
• Three-tier / n-tier: presentation, application logic, and data are separated
• Microservices: many small services, each owning a business capability
• Event-driven: components react to messages or events
• Peer-to-peer: nodes communicate more symmetrically, without one permanent center

A ride-sharing app like Uber uses multiple styles at once: mobile clients, backend services, databases, and event streams. The key question is not "Which architecture is best?" but "Which trade-offs fit this problem?"

Classic centralized styles: client-server and layered systems

The most familiar pattern is client-server: browsers or apps send requests, and a central server responds. Think of a restaurant: customers place orders, the kitchen does the work. This model is easy to reason about, secure, and monitor.

A common refinement is 3-tier architecture:

• Presentation layer: web or mobile UI
• Application layer: business logic like pricing or authentication
• Data layer: databases or caches

This separation helps teams change one layer without rewriting everything. For example, an online bookstore might have React in the frontend, a Java API in the middle, and PostgreSQL underneath.

But centralized designs can become bottlenecks. If one API server handles 10,000 requests per second, scaling often means adding load balancers and replicas around that center.

Decoupled styles: microservices and event-driven systems

When one codebase grows into a giant knot, teams often split it into microservices: small services with clear responsibilities, like payments, orders, and inventory. This is like replacing one huge department store with specialized shops. Each service can scale and deploy independently.

Event-driven architecture pushes decoupling further. Instead of directly calling another service, one component emits an event such as OrderPlaced, and others react.

{
  "event": "OrderPlaced",
  "orderId": 48152,
  "userId": 902,
  "total": 79.99
}

Now billing, shipping, analytics, and email can all respond without the order service knowing their details. This improves flexibility and throughput, especially in systems like Amazon or Netflix. The trade-off: debugging gets harder, because actions happen across time and across many services.

Symmetric systems: peer-to-peer and hybrid architectures

Not all distributed systems revolve around a central boss. In peer-to-peer (P2P) systems, nodes act more like equals. BitTorrent is the classic example: users download pieces of a file from many peers at once, which spreads load and avoids one overloaded server.

P2P can be powerful when:

• participants naturally contribute resources
• central infrastructure is expensive
• temporary disconnections are acceptable

But P2P is harder to control. Security, trust, and consistency become trickier because no single node has the full picture.

In practice, many real systems are hybrids. For example, Spotify uses centralized services for accounts and recommendations, but content delivery may use caches and distributed infrastructure close to users. Good architects mix styles rather than treating architecture like a religion.