Bird
Raised Fist0

Availability - Active-Active vs Active-Passive Failover Patterns

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

Send write request

Client issues a write to update user data

Protocol:WebSocket
BeforeUser data update only on client device
AfterWrite request sent over WebSocket to Load Balancer
Load Balancer / DNS

Route request to DB node

Load Balancer routes to active Cassandra node based on health and availability

Protocol:TCP
BeforeRequest received from client
AfterRequest forwarded to active Cassandra node
Write DB Cluster (Cassandra)

Commit write

Cassandra node writes data and replicates to other nodes (active-active) or primary only (active-passive)

Protocol:CQL
BeforeWrite request received at Cassandra node
AfterData durably stored and replicated per cluster mode
Read Cache (Redis Cluster)

Update cache

Redis cache updated with new data for fast reads

Protocol:Redis SET
BeforeCache has stale data
AfterCache updated with fresh data
Monitoring & Failover Service

Monitor cluster health

Continuously checks Cassandra node health and triggers failover if needed

Protocol:Heartbeat
BeforeCluster nodes assumed healthy
AfterFailover triggered if primary node fails (active-passive)
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│       Client Applications      │
└───────────────┬───────────────┘
                │ WebSocket
                ▼
┌───────────────────────────────┐
│       Load Balancer / DNS      │
└───────────────┬───────────────┘
                │ TCP
                ▼
┌───────────────────────────────┐
│  Write DB Cluster (Cassandra) │
│  (Active-Active or Passive)   │
└───────────────┬───────────────┘
                │ Redis SET
                ▼
┌───────────────────────────────┐
│   Read Cache (Redis Cluster)  │
└───────────────┬───────────────┘
                │ Heartbeat
                ▼
┌───────────────────────────────┐
│ Monitoring & Failover Service  │
│  (Detects node health, triggers│
│   failover in Active-Passive)  │
└───────────────────────────────┘
Design Rationale

This architecture illustrates the flow of a client write request through an availability-focused system using either active-active or active-passive failover patterns. The Client Applications send requests via WebSocket to the Load Balancer, which routes them to the active Cassandra node(s). In active-active mode, writes replicate across multiple nodes simultaneously, while in active-passive mode, writes go to a primary node with failover managed by the Monitoring & Failover Service. The Read Cache (Redis) is updated after writes to ensure low-latency reads. The Monitoring & Failover Service continuously monitors node health and triggers failover in active-passive setups, ensuring high availability. This design balances consistency, latency, and fault tolerance by combining distributed databases, caching, and health monitoring.

Primary Focus

✓

Practice

(1/5)
1. In the metrics collection system, at step 4 the Aggregation Worker receives a batch of metrics from Kafka. What happens if the Aggregation Worker detects a missing metric timestamp in this batch?
easy
A. The Aggregation Worker skips the missing timestamp metric and processes the rest of the batch
B. The Aggregation Worker inserts a default timestamp and continues processing
C. The Aggregation Worker pauses processing and waits for manual intervention
D. The Aggregation Worker discards the entire batch and requests a retry from Kafka

Solution

  1. Step 1: Aggregation Worker error handling

    Discarding entire batch (A) or pausing (C) causes unnecessary delays; default timestamps (D) risk data corruption.

  2. Step 2: Skipping invalid metrics

    Skipping only the invalid metric preserves throughput and data integrity for valid metrics.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Skip invalid metrics, process valid batch entries [check]
Hint: Skip bad metrics, keep batch flowing smoothly [check]
Common Mistakes:
2. For candidate-job matching, which architecture better supports real-time personalized recommendations with low latency and frequent profile updates?
medium
A. Precomputed static candidate-job similarity scores stored in a relational database
B. Batch processing with nightly offline model training and periodic reindexing
C. Online feature store with streaming updates feeding a real-time scoring service
D. Client-side filtering of job listings based on cached candidate preferences

Solution

  1. Step 1: Analyze real-time personalization needs

    Low latency and frequent profile updates require online, streaming data processing.

  2. Step 2: Evaluate architectures

    Batch (A) is too stale; static precomputed scores (C) can't adapt quickly; client-side filtering (D) lacks server-side intelligence. Online feature store with streaming (B) supports fresh data and low latency scoring.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Streaming updates + real-time scoring -> fresh personalized matches [check]
Hint: Streaming + online features enable fresh real-time recommendations [check]
Common Mistakes:
3. For a high-throughput system requiring SSL termination and HTTP header manipulation, which architecture is more appropriate and why?
medium
A. Use a Reverse Proxy for SSL termination and header manipulation because it operates at the HTTP layer with fine-grained control
B. Use an API Gateway for SSL termination and header manipulation because it is optimized for high throughput
C. Use a Load Balancer for SSL termination and header manipulation because it handles traffic efficiently
D. Use DNS load balancing to distribute SSL termination across multiple servers

Solution

  1. Step 1: Identify component capabilities

    Load Balancers typically operate at transport layer and may support SSL termination but lack detailed HTTP header manipulation; API Gateways add overhead and are less optimized for raw throughput; DNS load balancing does not handle SSL termination.

  2. Step 2: Match requirement to component

    Reverse Proxy operates at HTTP layer, supports SSL termination and header manipulation efficiently, suitable for high throughput.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Reverse Proxy = HTTP layer control + SSL termination [check]
Hint: Reverse Proxy = SSL termination + HTTP header control [check]
Common Mistakes:
4. You need to design a distributed configuration system that supports dynamic updates with strong consistency guarantees. Which approach is best suited for this scenario?
medium
A. Use Zookeeper to store configuration with watches for immediate update notifications
B. Use a distributed cache with eventual consistency and periodic refresh
C. Use a relational database with polling clients for configuration changes
D. Use a message queue to broadcast configuration changes asynchronously

Solution

  1. Step 1: Identify consistency and update requirements

    Strong consistency and immediate update notification are required.

  2. Step 2: Evaluate options

    Distributed cache with eventual consistency delays updates; relational DB polling adds latency; message queue is asynchronous without state storage.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Zookeeper watches -> immediate, consistent config updates [check]
Hint: Watches + strong consistency -> Zookeeper for config updates [check]
Common Mistakes:
5. At 10x traffic scale, which component in the cache warming architecture is most likely to become the bottleneck first, and why?
hard
A. The database, because it cannot handle the increased read load from the warming service
B. The network bandwidth, because warming floods the network with data transfers
C. The cache servers, because they run out of memory storing warmed keys
D. The cache warming coordinator, because it maintains global state and cannot shard effectively

Solution

  1. Step 1: Identify coordinator role and scaling limits

    The warming coordinator manages global warming state and task assignment, which is hard to shard.

  2. Step 2: Compare other components

    Database can be scaled with replicas; cache servers scale horizontally; network scales with capacity upgrades.

  3. Step 3: Conclude bottleneck

    Coordinator's centralized state causes it to fail first at 10x scale.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Centralized coordinator state limits sharding, causing bottleneck [check]
Hint: Central coordinator state limits sharding, causing bottleneck [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