Bird
Raised Fist0

Read Replicas and CQRS Pattern for Read-Heavy Systems

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Command Service

Receive command

Accepts client write request and validates input

Protocol:HTTP/REST
BeforeClient has submitted a write request
AfterCommand Service has validated and prepared SQL statement
Primary DB (PostgreSQL)

Execute write

Command Service writes data to Primary DB

Protocol:SQL (JDBC)
BeforePrimary DB has previous data state
AfterPrimary DB has new data committed
Kafka Topic

Publish event

Primary DB triggers event published to Kafka topic

Protocol:Kafka Producer
BeforeKafka topic does not have this event
AfterKafka topic contains new event reflecting data change
Read Replica DB Cluster (PostgreSQL)

Consume event and update

Kafka consumer applies event to read replica DB asynchronously

Protocol:Kafka Consumer + SQL (JDBC)
BeforeRead replicas have stale data
AfterRead replicas updated with new data asynchronously
Query Service

Serve read query

Query Service reads from Read Replica DB to respond to client

Protocol:SQL (JDBC)
BeforeClient requests data read
AfterClient receives data from read replica
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Command Service     │
│ (handles writes/cmds) │
└─────────────┬─────────┘
              │ SQL (JDBC)
              ▼
┌───────────────────────┐
│ Primary DB (Postgres) │
│ (master for writes)   │
└─────────────┬─────────┘
              │ Kafka Prod
              ▼
┌───────────────────────┐
│     Kafka Topic       │
│ (event stream updates)│
└─────────────┬─────────┘
              │ Kafka Cons
              ▼
┌───────────────────────┐
│ Read Replica DB Clstr │
│ (Postgres, read-only) │
└─────────────┬─────────┘
              │ SQL (JDBC)
              ▼
┌───────────────────────┐
│    Query Service      │
│  (handles read queries)│
└───────────────────────┘
Design Rationale

This architecture uses the CQRS pattern with read replicas to optimize read-heavy workloads. The Command Service handles all writes, updating the Primary DB synchronously. Changes are then published as events to a Kafka topic, which decouples write and read paths. The Read Replica DB Cluster asynchronously consumes these events to update read-only replicas, ensuring eventual consistency. The Query Service serves all read requests from these replicas, reducing load on the primary database and improving read scalability. This separation allows the system to handle high read throughput without impacting write performance.

Primary Focus

✓

Practice

(1/5)
1. In a consistent hashing system, at Step 4 the request router receives a key and queries the hash ring to find the responsible shard. What happens if the shard mapped by the hash ring is currently down?
easy
A. The router retries the same shard until it recovers before forwarding the request
B. The router uses the next clockwise shard on the hash ring as a fallback for the key
C. The router returns an error immediately to the client indicating shard unavailability
D. The router hashes the key again with a different hash function to find another shard

Solution

  1. Step 1: Trace request router behavior on shard failure

    Retrying the same shard (The router retries the same shard until it recovers before forwarding the request) blocks requests; returning error (The router returns an error immediately to the client indicating shard unavailability) reduces availability; next clockwise shard (The router uses the next clockwise shard on the hash ring as a fallback for the key) is correct only if the ring is intact and shard failure is handled by virtual nodes.

  2. Step 2: Understand fallback hashing

    Rehashing with a different function (The router hashes the key again with a different hash function to find another shard) is a common fallback to find an alternate shard when the primary is down, ensuring availability without blocking or errors.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Fallback hashing finds alternate shard on failure [check]
Hint: Fallback hashing finds alternate shard if primary is down [OK]
Common Mistakes:
2. A distributed file system must handle frequent small file metadata updates with low latency. Which component is primarily responsible for managing these metadata operations efficiently?
easy
A. Data Nodes storing actual file blocks and handling read/write requests
B. Client-side caching to reduce metadata server load
C. Metadata Servers maintaining namespace hierarchy and file metadata
D. Load balancers distributing client requests evenly across data nodes

Solution

  1. Step 1: Identify Metadata Server role

    Metadata Servers maintain the namespace and metadata such as file attributes and directory structure, handling frequent metadata updates.

  2. Step 2: Eliminate other components

    Data Nodes store file blocks but do not manage metadata; client caching reduces load but does not handle updates; load balancers distribute traffic but don't manage metadata.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Metadata Servers handle namespace and metadata updates efficiently [check]
Hint: Metadata Servers manage namespace and metadata updates [check]
Common Mistakes:
3. In the message delivery trace, at step 4 the Delivery Worker checks the subscriber's presence TTL in Redis. What happens if the TTL has expired at this step?
easy
A. The Delivery Worker forwards the message to a backup subscriber
B. The Delivery Worker marks the message as undeliverable and stops retries
C. The Delivery Worker queues the message for later retry after refreshing TTL
D. The Delivery Worker immediately retries delivery without delay

Solution

  1. Step 1: Understand Delivery Worker behavior on subscriber presence TTL expiry

    If TTL expired, subscriber is considered offline. Delivery Worker does not retry immediately (The Delivery Worker immediately retries delivery without delay) or mark undeliverable (The Delivery Worker marks the message as undeliverable and stops retries) because retries are needed. It does not refresh TTL (The Delivery Worker queues the message for later retry after refreshing TTL) as TTL is subscriber-driven.

  2. Step 2: Recognize fallback to backup subscriber for high availability

    Delivery Worker forwards message to backup subscriber or alternative delivery path to ensure eventual delivery.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL -> fallback delivery to backup subscriber [check]
Hint: Expired TTL triggers fallback delivery, not immediate retry [check]
Common Mistakes:
4. For a distributed task scheduler requiring high availability and exactly-once execution, which architecture is preferable and why?
medium
A. Use a centralized master node to assign tasks to workers synchronously
B. Use independent cron jobs on each worker node without coordination
C. Use a distributed priority queue with idempotent workers and lease-based locks
D. Use a replicated database with polling workers and no task locking

Solution

  1. Step 1: Evaluate centralized master node (A)

    Centralized master is a single point of failure and bottleneck, reducing availability.

  2. Step 2: Evaluate distributed priority queue with leases (B)

    Distributed queue with lease-based locks prevents duplicate execution, supports failover, and scales horizontally.

  3. Step 3: Evaluate cron jobs (C) and polling without locks (D)

    Cron jobs lack coordination causing duplicates; polling without locks risks multiple workers executing the same task.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Distributed queue + leases enable exactly-once and high availability [check]
Hint: Leases + distributed queue = exactly-once and HA [check]
Common Mistakes:
5. At 10x transaction volume, which component is most likely to become the first bottleneck in the payment system, and why?
hard
A. The client SDK, because it cannot handle increased retry logic under load
B. The Idempotency Store, because it is a centralized stateful component with limited horizontal scaling
C. The Settlement Service, due to batch processing delays and database write contention
D. The load balancer, as it cannot distribute traffic evenly at very high request rates

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    The Idempotency Store holds global state and is hard to shard, limiting horizontal scaling.

  2. Step 2: Evaluate other components

    Settlement Service can be scaled with partitioned batches; client SDK is client-side and less critical; load balancer scales horizontally with modern tech.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized idempotency store -> scaling bottleneck at 10x load [check]
Hint: Centralized stateful store limits scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard