System Design interview questions: architecture practice quiz

By definition, a monolith is a single deployable artifact. All components are tightly coupled and compiled/packaged together. Any code change—regardless of which layer it affects—requires rebuilding and redeploying the whole unit. This is one of the key motivations for moving toward microservices, which allow individual components to be deployed independently.

A load balancer sits in front of a pool of servers and distributes client requests using algorithms such as round-robin or least-connections. When an application stores session state locally on a specific server, a 'sticky session' (also called session affinity) configuration tells the load balancer to always route a given client to the same backend server so that session data remains accessible. This avoids the need to share session state across servers but can create uneven load distribution.

Stateless architecture means no session or user state is persisted on individual application servers. Session data is either stored in a shared external store (e.g., Redis, a database) or encoded in the request itself (e.g., a signed JWT). Because no server holds unique local state, any server can serve any request, making horizontal scaling and failover straightforward. This is a foundational principle behind scalable, cloud-native architectures.

Statements 1, 2, and 4 are correct. Write-through (Statement 1) synchronously writes to both the cache and the database on every write, keeping them consistent for written keys at the cost of higher write latency. Write-behind / write-back (Statement 2) writes to the cache first and flushes to the database asynchronously, improving write throughput. Write-behind (Statement 4) does risk data loss: if the cache node crashes before the asynchronous flush completes, those pending writes are lost.

Statement 3 is false. Write-through has higher write latency than write-behind because it must wait for both the cache write and the synchronous database write to complete before acknowledging success; write-behind returns as soon as the cache write is done.

Statement 5 is false. Read-through is a reactive (lazy) strategy: the cache intercepts a read, detects a miss, fetches the data from the database on behalf of the caller, populates the cache, and then returns the result. Proactive pre-population before any miss occurs describes cache warming (or cache priming), not read-through.

In a multi-region active-active architecture, the core challenge with eventual consistency is handling concurrent writes to the same record from different regions. Vector clocks (or similar mechanisms like CRDTs) track causality across nodes so that conflicts can be detected and resolved rather than silently overwriting data. Last-Write-Wins (LWW) based solely on wall-clock time is unsafe because clocks can skew, making it possible to overwrite a newer write with an older one. Two-phase commit provides strong consistency but introduces cross-region coordination latency and is an availability risk — the opposite of what active-active targets. Read repair is a read-path technique and does not prevent write conflicts. Vector clocks remain the standard causality-tracking answer for active-active replication conflict detection.

The question tests deep understanding of the CAP theorem applied to a concrete split-brain scenario. First, the system must detect the partition — without detection, no decision can be made. Second, nodes must identify majority vs. minority — this quorum assessment is a prerequisite to knowing which side to suppress or allow. Third, the architect must consult the system's SLA to decide between CP and AP behaviour. Fourth, the system enforces that decision: an AP system (e.g., Cassandra, DynamoDB) accepts writes on both sides and logs divergence; a true CP system (e.g., etcd, ZooKeeper — both Raft/Paxos-based) outright rejects writes that cannot achieve quorum on the minority side — queuing writes would defer the consistency decision and is an AP-leaning strategy, not CP. Finally, after healing, AP systems perform conflict resolution (LWW, vector clocks, CRDTs); CP systems simply re-sync minority nodes from the authoritative majority log, because those minority nodes accepted no writes and have nothing to replay.

This question probes several common but costly misconceptions in large-scale system design. (1) Adding a CDN for database query caching is FALSE — CDNs cache static or edge-cacheable HTTP responses, not raw database queries; that role belongs to an in-process or distributed cache like Redis. (2) A message queue (e.g., Kafka, SQS) decouples producers from consumers and naturally absorbs traffic spikes by acting as a buffer, so bursts don't overwhelm downstream services — TRUE. (3) Horizontal scaling of stateful services is NOT simply a matter of adding instances; state must be externalised or partitioned (sharding, consistent hashing) to avoid split-brain and inconsistency — FALSE. (4) Database read replicas reduce load on the primary by offloading read traffic — TRUE. All four require careful evaluation, making this a multi-select question.

All four techniques are valid strategies for avoiding hot partitions in high-throughput distributed systems. Consistent hashing with virtual nodes spreads load evenly across nodes and handles node churn gracefully. Write-behind caching absorbs burst writes before they hit the storage layer. Shard splitting (range sub-partitioning) breaks a hot shard into smaller shards to distribute the hot key range. However, simply adding read replicas only helps with read-heavy hot spots; it does NOT alleviate write hot spots because all writes must still go to the primary. If the hot partition is write-heavy — the most common production scenario — read replicas are ineffective. The question asks which strategy does NOT generally mitigate a write-skewed hot partition, making read replicas the correct answer.

This question probes deep understanding of consensus, replication, and failure-domain design in globally distributed systems. (1) Synchronous cross-region replication is correct — it guarantees no data loss (RPO=0) but sacrifices availability during partition (violates the 'stays available' requirement). (2) Asynchronous replication with tunable staleness is correct — it keeps the system available but risks data loss on region failure, so it does NOT give RPO=0. (3) Multi-master active-active with CRDTs is correct — CRDTs provide availability and eventual consistency but do NOT guarantee strong consistency or zero divergence on conflicting writes. (4) Paxos/Raft-based geo-consensus IS the canonical approach to achieve both strong consistency and high availability across regions when paired with enough quorum members in distinct failure domains, but it trades off latency (write latency ≥ cross-region RTT). So the claim that Paxos/Raft 'cannot provide both' is FALSE — it is exactly what systems like Google Spanner and CockroachDB implement. The question asks which statement is FALSE, so the answer is the Paxos/Raft option.

The defensible canonical progression follows the 'concrete operational pain at each step' principle from Richardson's Microservices Patterns and Newman's Building Microservices: (1) Monolith — proves product-market fit with minimal operational complexity. (2) Message queue / microservice decomposition — synchronous bottlenecks and tight coupling become painful under load; introducing Kafka and drawing service boundaries enables independent deployment but immediately removes the monolith's ACID transaction guarantee. (3) Saga orchestration — as Richardson explicitly argues, the first architectural problem exposed by microservice decomposition is the loss of distributed ACID transactions; sagas (orchestration or choreography) must be introduced at this point to manage compensating transactions across service boundaries before any further persistence changes are layered on. (4) CQRS — once service boundaries are stable and transactions are safely coordinated by sagas, read and write workloads diverge sharply; CQRS separates the command model from read projections and is a lower-risk prerequisite for event sourcing because it can be applied to ordinary state-mutation services. (5) Event sourcing — building on the already-separated command model and saga-coordinated boundaries, mutable state is replaced with an immutable event log in a dedicated event store (e.g., EventStoreDB); CQRS projections already in place make this migration far less risky. Event sourcing does not require the message queue as a technical prerequisite, but sagas and CQRS being in place dramatically reduce the blast radius. (6) Geo-replication — only after the event-sourced architecture is stable does replicating the event log across regions become operationally safe and worthwhile; attempting geo-replication before the write model is settled multiplies operational risk.