Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
In modern distributed system design, scaling databases is a fundamental challenge. Read replicas and write scaling represent two distinct strategies for handling increased load. Read replicas address read-heavy traffic by distributing queries across multiple secondary nodes, while write scaling requires more complex architectural decisions like sharding or partitioning to overcome the single-writer bottleneck. In 2026, as applications demand lower latency and higher availability, interviewers frequently test candidates on their ability to distinguish between these approaches. Junior engineers are expected to explain the basics of master-slave replication and its impact on read throughput. Senior engineers must demonstrate deep knowledge of replication lag, the trade-offs of synchronous versus asynchronous replication, and the architectural complexity of horizontal write scaling (sharding). Understanding when to apply read replicas versus when to re-architect for write scaling is a high-signal indicator of a candidate's system design maturity.
The choice between read replicas and write scaling is often the difference between a system that scales linearly and one that hits a hard wall. Read replicas are the 'low-hanging fruit' of database scaling; they provide immediate relief for read-intensive workloads (e.g., social media feeds, content delivery) with minimal application-level changes. However, they do not solve the write bottleneck. If a system is write-bound, adding replicas actually increases the load on the primary node due to replication overhead. Write scaling, conversely, requires fundamental changes like sharding, which introduces significant operational complexity, including cross-shard transactions and rebalancing challenges. In 2026, with the rise of globally distributed services, engineers must manage the 'read-your-writes' consistency problem, where a user writes data to the primary but reads stale data from a lagging replica. A strong candidate understands that write scaling is not just about adding hardware; it is about partitioning the data space to distribute the write load. Weak answers often conflate read scaling with write scaling, suggesting replicas as a universal solution, which demonstrates a lack of understanding regarding the fundamental limits of primary-node throughput.
The architecture involves a primary node handling all write operations and multiple secondary nodes (replicas) handling read traffic. Writes are streamed via a Write-Ahead Log (WAL) or binary log to replicas. Read scaling is achieved by load balancing queries across the replica pool, while write scaling requires a sharding layer to direct writes to distinct primary instances.
Writes land on the Primary, which updates its local state and asynchronously pushes updates to Replicas. Reads are routed by the Load Balancer to any available Replica. If write capacity is exceeded, the Sharding Middleware intercepts requests and routes them to the correct Shard.
[Client Requests]
↓
[Load Balancer / Proxy]
↓ ↓
[Primary Node] [Replica 1] → [Replica 2]
↓ (WAL) ↓ (Read) ↓ (Read)
[Sharding Layer] ← [Replica 3] ← [Replica 4]
↓
[Shard A] [Shard B] [Shard C]Store the last write timestamp in a user's session and force reads to the primary if the replica lag is higher than the time since the last write.
Trade-offs: Increases load on the primary node; requires session state management.
Use a consistent hashing algorithm on a shard key (e.g., user_id) to map write requests to specific database shards at the application or proxy layer.
Trade-offs: Hard to rebalance shards; potential for data skew if keys are not distributed.
Separate the write model (commands) from the read model (queries) to allow independent scaling of read and write paths.
Trade-offs: High complexity; requires robust event synchronization between models.
| Reliability | Use semi-synchronous replication to balance data safety and performance; implement automated failover to promote a replica to primary. |
| Scalability | Scale reads horizontally by adding replicas; scale writes horizontally by sharding data across multiple independent primary clusters. |
| Performance | Monitor replication lag in milliseconds; use connection pooling to manage the increased number of client connections. |
| Cost | Replicas increase compute and storage costs; sharding increases operational overhead and management costs. |
| Security | Encrypt replication streams; restrict access to the primary node; use IAM roles for cross-node authentication. |
| Monitoring | Track replication lag, primary CPU utilization, write throughput, and connection pool saturation. |
No. Read replicas are designed specifically to offload read traffic. Adding replicas actually increases the write load on the primary node because the primary must stream updates to every replica.
Read replicas copy the entire dataset to multiple nodes to scale reads. Sharding splits the dataset into smaller chunks (shards) across multiple nodes to scale both reads and writes.
Replication lag occurs because the primary node processes writes faster than the replica can apply them, or because of network delays in streaming the logs to the replica.
You can route the user's read requests to the primary node for a short period after they perform a write, or use session-based routing to ensure they read from a replica that is caught up.
No. Sharding introduces significant operational complexity, including cross-shard transactions and rebalancing. Vertical scaling is simpler and should be exhausted before considering sharding.
The CAP theorem highlights the trade-off between consistency and availability. In read-scaled systems, we often choose Availability and Partition Tolerance (AP) by accepting eventual consistency (replication lag).
A shard key is a column or set of columns used to determine which shard a piece of data belongs to. The choice of shard key is critical for balancing write load evenly.
Synchronous replication waits for the replica to acknowledge the write before committing, ensuring consistency but increasing latency. Asynchronous replication commits immediately, prioritizing performance.
Sharding makes global indexes difficult to maintain. Most sharded systems use local indexes within each shard, which makes cross-shard queries slower and more complex.
A hot shard occurs when a specific shard receives a disproportionate amount of write traffic, usually due to a poorly chosen shard key that leads to data skew.
Yes, read replicas are often used to perform backups to avoid putting load on the primary node, which is a common production best practice.
A database proxy sits between the application and the database to intelligently route queries, handle connection pooling, and manage failover, often abstracting the complexity of sharding.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.