Bird
Raised Fist0

Why Distributed Locks Are Needed and Why They Are Hard to Get Right

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Distributed Clients

Send lock acquisition request

Client attempts to acquire a distributed lock before updating metadata

Protocol:WebSocket
BeforeClient has local update ready but no lock acquired
AfterLock acquisition request sent to Load Balancer
Load Balancer

Forward lock request

Routes client request to one Lock Service instance

Protocol:HTTP REST
BeforeLoad Balancer idle, waiting for requests
AfterLock request forwarded to Lock Service
Lock Service (Redis)

Attempt lock acquisition using Redlock

Sets Redis key with NX and TTL to ensure lock uniqueness and expiry

Protocol:Redis SET with NX + TTL
BeforeLock key does not exist or expired
AfterLock key set if no existing lock, lock granted or denied
Metadata Store

Update metadata after lock acquired

Client updates shared metadata safely under lock protection

Protocol:CQL Query
BeforeMetadata in Cassandra is consistent but stale
AfterMetadata updated atomically with lock held
Lock Service (Redis)

Release lock

Deletes Redis key to release lock after update completion

Protocol:Redis DEL
BeforeLock key exists and client holds lock
AfterLock key deleted, lock released for others
Monitoring System

Monitor lock service health and failures

Detects lock acquisition failures or Redis unavailability

Protocol:Polling/Alerts
BeforeLock Service operational with normal metrics
AfterAlerts triggered if lock failures or Redis issues detected
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Distributed Clients │
└─────────────┬─────────┘
              │ WebSocket
              ▼
┌───────────────────────┐
│     Load Balancer     │
└─────────────┬─────────┘
              │ HTTP REST
              ▼
┌─────────────────────────┐
│   Lock Service (Redis)  │
│    with Redlock algo    │
└─────────────┬───────────┘
              │ Redis SET NX + TTL
              ▼
┌───────────────────────┐
│   Metadata Store      │
│   (Cassandra DB)      │
└─────────────┬─────────┘
              │ CQL Query
              ▼
┌───────────────────────┐
│ Monitoring System     │
└───────────────────────┘
Design Rationale

Distributed locks coordinate access to shared resources in distributed systems. Here, clients request locks via a Load Balancer to a Redis-based Lock Service implementing the Redlock algorithm. The lock is acquired by setting a Redis key with NX and TTL to ensure exclusivity and automatic expiry. Once the lock is held, clients safely update shared metadata in Cassandra. After updates, the lock is released by deleting the Redis key. The Monitoring System tracks lock service health and failures, crucial because distributed locks are hard to get right due to network delays, partial failures, and clock drift. This architecture highlights the complexity of ensuring correctness and availability in distributed locking.

Primary Focus

✓

Practice

(1/5)
1. In a chat system request flow, at Step 4 the Delivery Worker checks the recipient's online status cache. What happens if the cache entry is expired at this step?
easy
A. Delivery Worker falls back to persistent message queue for offline delivery
B. Delivery Worker immediately marks message as delivered
C. Delivery Worker drops the message assuming recipient is offline
D. Delivery Worker retries checking cache indefinitely

Solution

  1. Step 1: Understand Delivery Worker role at Step 4

    It checks recipient online status cache to decide delivery method.

  2. Step 2: Behavior on expired cache entry

    Expired cache means unknown status; system falls back to persistent queue to ensure message is not lost.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired cache triggers fallback to persistent queue [check]
Hint: Expired cache triggers fallback, not message drop or infinite retry [check]
Common Mistakes:
2. A large-scale analytics system needs to estimate the frequency of millions of distinct events in real-time with limited memory. Which component is best suited to provide approximate frequency counts efficiently?
easy
A. A Count-Min Sketch data structure with multiple hash functions
B. A distributed cache storing exact counts per event key
C. A relational database with indexed counters for each event
D. A Bloom filter to track event presence without counts

Solution

  1. Step 1: Identify approximate frequency counting need

    Relational DBs and caches store exact counts but require large memory and are slow at scale.

  2. Step 2: Recognize Count-Min Sketch properties

    Count-Min Sketch uses multiple hash functions and fixed memory to estimate frequencies with bounded error.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Count-Min Sketch approximates frequencies with fixed memory and multiple hashes [check]
Hint: Count-Min Sketch trades memory for approximate frequency counts [check]
Common Mistakes:
3. A company wants to decouple rapid feature deployments from the risk of impacting the entire system. Which architectural approach best supports this requirement?
easy
A. A microservices architecture with independently deployable services
B. A layered monolith with a shared database and common deployment
C. A monolithic architecture with modular codebase and feature flags
D. A serverless architecture with tightly coupled functions

Solution

  1. Step 1: Identify deployment isolation needs

    Decoupling feature deployments requires independent service lifecycles, which microservices provide.

  2. Step 2: Evaluate alternatives

    Monoliths (A and C) share deployment units, risking system-wide impact. Serverless (D) can be tightly coupled if functions share state or deployment.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Microservices enable independent deploys and reduce blast radius [check]
Hint: Independent deploys need microservices, not just modular code [check]
Common Mistakes:
4. For a globally distributed collaborative editor with many offline users, which approach better supports eventual consistency and offline edits, and why?
medium
A. Use Operational Transformation (OT) because it requires a central server to order operations
B. Use a relational database with strict locking to serialize all edits globally
C. Use CRDTs because they allow local operations to be merged without coordination and support offline edits
D. Use a message queue with timestamp ordering to ensure global operation order

Solution

  1. Step 1: Compare OT and CRDT for offline and distributed scenarios

    OT typically requires a central server to order and transform operations, making offline support complex.

  2. Step 2: Understand CRDT advantages

    CRDTs are designed for decentralized environments, allowing local operations to be merged eventually without coordination, ideal for offline edits and global distribution.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CRDTs enable offline edits and eventual consistency without central coordination [check]
Hint: CRDTs merge offline edits without central coordination [OK]
Common Mistakes:
5. You need to model a social media feed with millions of users and high write throughput. Which data modeling approach is best to optimize for write scalability and read performance?
medium
A. Embed all posts and comments inside each user document to minimize joins.
B. Use a graph database to model user relationships and posts for efficient traversal.
C. Store all posts in a single collection with a compound index on user and timestamp for fast queries.
D. Use a referencing pattern with separate collections for users, posts, and comments, and denormalize popular posts into user feed documents.

Solution

  1. Step 1: Analyze write scalability and read patterns

    High write throughput and millions of users require scalable writes and efficient feed reads.

  2. Step 2: Evaluate referencing with denormalization

    Referencing separates concerns; denormalizing popular posts into feeds optimizes read performance without large documents.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Referencing plus denormalization balances write scale and read speed [check]
Hint: Reference plus denormalize popular data for scalable writes and fast reads [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