6 Foundations of distributed system design
This chapter equips frontend engineers with the core concepts of distributed systems so they can design end-to-end solutions, collaborate across teams, and perform strongly in system design interviews. It argues that the traditional boundary between frontend and backend is fading, and that understanding trade-offs—between simplicity and modularity, consistency and availability, performance and cost—is now a differentiator. The material is organized around fundamentals-to-advanced progressions and ties each topic to the kinds of questions and scenarios candidates should expect.
The content surveys architectural paradigms from monoliths and layered designs to n-tier systems and microservices, including migration strategies that emphasize separation of concerns and patterns like Hexagonal and Onion Architecture. It builds a foundation in distributed computing—CAP theorem, consistency models, consensus protocols, and real-world constraints such as latency, partitions, and partial failures—before moving into scalability: vertical vs. horizontal scaling, load balancing strategies, session affinity, regional routing, and autoscaling. Caching is treated as a multi-layer discipline (client, CDN, application, database, and distributed caches) with guidance on invalidation and avoidance of stampedes; data strategies cover replication, sharding, and partitioning, along with the operational implications of lag, hot shards, and cross-shard behavior. Communication, observability, and monitoring round out the reliability toolkit, highlighting metrics, logs, traces, health checks, and automated remediation.
Throughout, the chapter translates theory into interview-ready practice: explaining CORS and API proxy setups in multi-tier deployments, outlining steps to modularize a monolith, demonstrating how to tune load balancers and autoscaling policies (e.g., with request and latency metrics), and showing how to select cache strategies and shard keys based on access patterns. Candidates are coached to reason explicitly about trade-offs (CP vs. AP choices, strong vs. eventual consistency, sync vs. async replication), to measure and mitigate risks (replica lag, hotspotting, backpressure), and to design with observability and self-healing in mind. The result is a concise playbook that helps frontend engineers speak fluently about distributed system design and make sound, pragmatic decisions under interview pressure.
3-tier architecture
N-tier architecture
Microservices architecture
A random dog image fetched and displayed via a proxied API request.
Hexagonal Architecture of the user management domain.
Onion Architecture of the user management domain.
Vertical scaling: from 2 CPU and 4 GB RAM to 8 CPU and 32 GB RAM
Horizontal scaling: from one server to three servers.
Load balancer processes a request.
Overview of caching strategies in system design
Sample execution of the LRU cache demo
Sharded caches with Redis fallback
Example: User account data (profiles, settings, and permissions) is written to the Primary DB, then replicated asynchronously into two Replica DB nodes that handle all read traffic for dashboards and profile views.
Sharding (horizontally partitioning)
Vertical partitioning
Automated monitoring and self-healing
Summary
- Modern software systems evolve through distinct architectural models, from monoliths and layered designs to microservices.
- The CAP theorem states that a distributed system can guarantee only two of the three properties—consistency, availability, and partition tolerance—at the same time.
- While Paxos is a complex consensus algorithm, Raft is more widely adopted in real-world distributed infrastructure.
- Horizontal scaling is preferred in modern system design to improve scalability and resilience.
- Distributed and multi-tier caching strategies are key to optimizing performance.
- Scalable and resilient systems rely heavily on distributing and duplicating data effectively.
- Communication, observability, and monitoring are essential components that underpin the operational reliability of distributed systems.
FAQ
Why should a frontend engineer understand distributed systems?
Because the line between frontend and backend is blurring. Frontend engineers increasingly integrate complex APIs, orchestrate cloud workflows, and diagnose end-to-end performance. Knowing distributed systems improves system design, collaboration with backend teams, interview performance, and opens opportunities to work on modern, scalable architectures.How do monoliths, 3-tier/n-tier, and microservices compare, and when should each be used?
- Monolith: Single deployable unit; simple to build/test, but hard to scale and modernize as complexity grows. Good for MVPs and internal tools.- 3-tier: Presentation, application, data layers; clear separation of concerns; traditional web apps with REST/GraphQL.
- N-tier: Adds specialized layers (CDN, auth, caching); better scalability and modularity, at the cost of complexity and potential latency between tiers; common in enterprise systems.
- Microservices: Small, independently deployable services with their own data; enables team autonomy and horizontal scaling, but requires strong orchestration, observability, and consistency patterns (e.g., sagas).
How do you handle CORS when frontend and backend are on different origins?
- Understand the same-origin policy: browsers block cross-origin requests unless the server allows them.- Configure backend (or API gateway/ingress) to send CORS headers: Access-Control-Allow-Origin (explicit origin for credentialed requests), Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Credentials (true if cookies/tokens are needed).
- Handle preflight (OPTIONS) requests for custom headers or non-simple methods.
- In production, restrict allowed origins; during development, allow localhost or use a dev proxy to avoid CORS friction.
Why use a development API proxy (e.g., Vite), and how does it help?
- Why: Avoids CORS issues by routing API calls through the dev server so requests appear same-origin; simplifies frontend code paths; eases switching among dev/staging/prod backends.- How (conceptually): Configure a path prefix (e.g., /apiproxy) that the dev server forwards to the API target, enables changeOrigin, and rewrites the path to the real backend route.
- Benefits: No backend CORS changes needed for local dev, cleaner DX, and simple environment routing.
What does the CAP theorem say, and can a system be consistent, available, and partition-tolerant simultaneously?
The CAP theorem says that under a network partition, a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response). Because real systems must tolerate partitions, you typically design for CP (e.g., HBase) or AP (e.g., DynamoDB/eventual consistency) trade-offs depending on business requirements.What’s the difference between strong and eventual consistency, and where is each appropriate?
- Strong consistency: Reads return the latest write across nodes. Use for correctness-critical domains (e.g., financial ledgers, many relational DB transactions like PostgreSQL).- Eventual consistency: Reads may be stale temporarily, but converge over time. Use for high-availability, high-scale systems where slight staleness is acceptable (e.g., Cassandra, DynamoDB, DNS).
- Intermediate models exist (e.g., causal, read-your-writes, monotonic reads) to balance UX and performance.
Vertical vs. horizontal scaling—what’s the difference, and how do load balancers enable horizontal scale?
- Vertical scaling: Add CPU/RAM to one machine; simple but limited and a single point of failure.- Horizontal scaling: Add more instances; better elasticity and fault tolerance but needs state management and orchestration.
- Load balancer: Acts as a reverse proxy, health-checks instances, and routes requests via algorithms (round-robin, least-connections, weighted, IP-hash/sticky sessions). Enables even traffic distribution, failover, and transparency to clients.
What is autoscaling, and how would you set it up for a Kubernetes API?
- Autoscaling automatically adjusts capacity to match load, improving responsiveness and cost efficiency.- In Kubernetes, define CPU/memory requests/limits on your Deployment, then use a Horizontal Pod Autoscaler (HPA) to scale pods based on metrics (e.g., target 70% CPU, min/max replicas). For advanced needs, expose custom metrics (RPS/latency/queue depth) via Metrics Server and Prometheus Adapter. Combine with Cluster Autoscaler to add/remove nodes when the cluster is full.
What are common caching layers and how do they work together?
- Client-side: Browser storage and HTTP caching headers to avoid network trips for static assets and some API responses.- CDN: Edge caching for static and cacheable dynamic content; control via Cache-Control, ETag, Expires; support purge/invalidation and stale-while-revalidate.
- Application-level: In-process or shared caches (Redis/Memcached); strategies include cache-aside and write-through; beware stampedes and eviction policies.
- Database-level: Buffer pools, query caches, materialized views; leverage partition pruning/indices.
- Distributed/multi-tier: Orchestrate client → edge → app → DB; tune TTLs, invalidation, and consistency. LRU is a common eviction policy that removes the least recently used items to keep hot data in memory.
How do replication, sharding, and partitioning differ, and what challenges should you expect?
- Replication: Copy the same data to multiple nodes for availability and read scaling (leader–follower or quorum-based). Watch replica lag and tune sync vs. async behavior; monitor via pg_stat_replication (PostgreSQL) or rs.status() (MongoDB).- Sharding (horizontal partitioning): Split data by key across nodes to scale writes and storage; choose shard keys carefully to avoid hotspots and support query locality; plan for rebalancing.
- Partitioning (within a database): Split large tables into partitions (range/list/hash) for manageability and faster queries (partition pruning). Choose strategies that match data shape and access patterns.
Acing the Frontend Interview ebook for free
