Bird
Raised Fist0

ACID Properties - Atomicity, Consistency, Isolation, Durability Deep Dive

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

Send transaction request

Client sends a transaction start request with operations

Protocol:WebSocket
BeforeClient has transaction operations ready to send
AfterTransaction request received by Transaction Coordinator
Transaction Coordinator

Acquire locks

Requests locks from Distributed Lock Manager to ensure isolation

Protocol:RPC (gRPC)
BeforeTransaction Coordinator has received transaction request
AfterLocks acquired for transaction operations
Distributed Lock Manager

Grant locks

Grants locks on data items to Transaction Coordinator

Protocol:RPC (gRPC)
BeforeLock requests pending from Transaction Coordinator
AfterLocks granted and recorded for transaction
Distributed Storage Layer

Apply transaction writes

Writes data changes atomically and consistently

Protocol:RPC (gRPC)
BeforeLocks held, ready to write data
AfterData changes applied but not yet durable
Replication & WAL Log

Append WAL and replicate

Durably logs transaction changes and replicates to backups

Protocol:WAL Append
BeforeData changes applied in storage layer
AfterTransaction changes durably logged and replicated
Transaction Coordinator

Commit transaction

Releases locks and confirms transaction success to client

Protocol:WebSocket
BeforeTransaction changes durably logged and replicated
AfterClient notified of successful transaction commit
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Client Applications │
└─────────────┬─────────┘
              │ WebSocket
              ▼
┌───────────────────────────────┐
│   Transaction Coordinator     │
│  - manages transaction states │
└─────────────┬─────────────────┘
              │ RPC (gRPC)
              ▼
┌───────────────────────────────┐
│   Distributed Lock Manager    │
│  - enforces isolation via locks│
└─────────────┬─────────────────┘
              │ RPC (gRPC)
              ▼
┌───────────────────────────────┐
│   Distributed Storage Layer   │
│  - stores data with consistency│
└─────────────┬─────────────────┘
              │ WAL Append
              ▼
┌───────────────────────────────┐
│   Replication & WAL Log       │
│  - ensures durability & backup│
└───────────────────────────────┘
Design Rationale

This architecture enforces ACID properties through a coordinated flow. The Client Applications initiate transactions via WebSocket to the Transaction Coordinator, which manages atomicity by controlling the transaction lifecycle. To ensure isolation, the Transaction Coordinator requests locks from the Distributed Lock Manager before applying changes. The Distributed Storage Layer applies data writes consistently under these locks. Durability is guaranteed by appending changes to the Replication & WAL Log, which replicates data to backups. Finally, the Transaction Coordinator commits the transaction and notifies the client. This vertical flow highlights how each component enforces a specific ACID property, ensuring reliable and consistent distributed transactions.

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 distributed cache system needs to assign keys to cache nodes such that when nodes are added or removed, minimal keys are remapped. Which component or technique best handles this requirement?
easy
A. Use a simple modulo-based hash function on node count to assign keys
B. Use a centralized directory service mapping keys to nodes
C. Assign keys randomly to nodes and rebalance periodically
D. Implement consistent hashing with virtual nodes to distribute keys

Solution

  1. Step 1: Understand key remapping minimization

    Simple modulo hashing (Use a simple modulo-based hash function on node count to assign keys) causes massive remapping when node count changes; random assignment (Assign keys randomly to nodes and rebalance periodically) lacks stability; centralized directory (Use a centralized directory service mapping keys to nodes) adds single point of failure and latency.

  2. Step 2: Consistent hashing with virtual nodes

    Consistent hashing distributes keys on a ring, and virtual nodes smooth load; adding/removing nodes only remaps a small subset of keys.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Consistent hashing minimizes key remapping on node changes [check]
Hint: Consistent hashing minimizes remap on node changes [check]
Common Mistakes:
3. A distributed system requires a lock mechanism that ensures mutual exclusion across multiple Redis instances with minimal risk of deadlocks. Which component or approach best handles this requirement?
easy
A. Implement Redlock algorithm coordinating locks across multiple Redis masters
B. Use a relational database row lock with distributed transactions
C. Use a single Redis instance with SETNX and expire for locking
D. Use a centralized ZooKeeper lock service for distributed locking

Solution

  1. Step 1: Understand distributed lock requirements

    Single Redis instance with SETNX risks single point of failure and split-brain issues.

  2. Step 2: Evaluate Redlock's multi-instance coordination

    Redlock uses multiple Redis masters to reduce risk of deadlocks and ensure safety under partial failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Redlock coordinates multiple Redis masters for safer distributed locks [check]
Hint: Multiple Redis masters coordinated -> safer distributed locks [check]
Common Mistakes:
4. If the Signaling Server crashes after forwarding Alice's SDP offer but before receiving Bob's answer, what is the most likely failure observed by Alice?
medium
A. Alice's client receives an immediate error indicating call failure
B. Alice's UI shows ringing indefinitely; the call never connects and no retry occurs
C. The media server starts relaying media streams without session establishment
D. Bob receives the offer twice causing duplicate call setup attempts

Solution

  1. Step 1: Trace failure impact of Signaling Server crash after forwarding offer

    If the server crashes before recording the offer state, it may resend the offer when restarted, causing duplicates.

  2. Step 2: Analyze other options

    No immediate error (A) is unlikely; indefinite ringing (B) happens if answer lost but not duplicated; media server (D) does not start without signaling.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Signaling crash causes duplicate offers, confusing Bob's client [check]
Hint: Signaling crash -> duplicate offers, not silent failure [check]
Common Mistakes:
5. At 10x current scale, which component in the Reddit voting and ranking system is most likely to fail first, and why?
hard
A. The relational database storing user profiles, due to increased read queries
B. The ranking service's in-memory cache, because it cannot shard scores by post_id effectively
C. The WebSocket servers maintaining live connections, because stateful connections cannot be resharded easily
D. The Kafka cluster, due to partition leader election delays under heavy load

Solution

  1. Step 1: Analyze stateful vs stateless components at scale

    Relational DB (The relational database storing user profiles, due to increased read queries) can be scaled with read replicas; Kafka (The Kafka cluster, due to partition leader election delays under heavy load) scales well with partitions. Ranking cache (The ranking service's in-memory cache, because it cannot shard scores by post_id effectively) can shard by post_id.

  2. Step 2: Identify WebSocket server bottleneck

    WebSocket servers hold stateful connections bound to server memory; these connections cannot be moved easily, limiting horizontal scaling and causing failures under 10x load.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers fail first due to unshardable live connections [check]
Hint: Stateful WebSocket servers bottleneck at 10x scale [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