Bird
Raised Fist0

Availability Numbers - What 99.9 vs 99.99 vs 99.999 Percent Means in Practice

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

Receives client availability update request

Client sends availability update via WebSocket

Protocol:WebSocket
BeforeClient has availability update ready to send
AfterAPI Gateway received update and forwards to Write Service
Write Service

Produces message to Kafka Cluster

Write Service serializes update and sends to Kafka topic

Protocol:Kafka Produce
BeforeWrite Service has availability update from API Gateway
AfterUpdate message durably stored in Kafka Cluster
Kafka Cluster

Queues message for consumption

Kafka stores message with replication for durability

Protocol:Kafka Consume
BeforeMessage stored in Kafka topic partition
AfterMessage ready for Write Service consumer to process
Write Service

Consumes message from Kafka and updates Redis Cache

Write Service reads message and sets availability in Redis

Protocol:Redis SET
BeforeRedis Cache has stale availability data
AfterRedis Cache updated with latest availability data
Write Service

Writes availability update to Cassandra DB

Write Service persists update for durable storage

Protocol:Cassandra Write
BeforeCassandra DB has previous availability state
AfterCassandra DB stores latest availability update, ensuring durable persistence
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────┐
│ Write Service │
└───────┬───────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────┐
│ Write Service │
│ (Consumer)    │
└───────┬───────┘
        │ Redis SET
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ Cassandra Write
        ▼
┌───────────────┐
│ Cassandra DB  │
└───────────────┘
Design Rationale

This architecture demonstrates how availability updates flow through a system designed for high durability and low latency. The API Gateway receives client requests and forwards them to the Write Service, which produces messages to a Kafka Cluster ensuring durable, ordered delivery. The Write Service then consumes these messages to update the Redis Cache for fast reads and persists the data in Cassandra DB for durable storage. This layered approach illustrates the trade-offs between availability and latency, showing how caching and durable queues contribute to achieving 99.9%, 99.99%, or 99.999% availability levels in practice.

Primary Focus

✓

Practice

(1/5)
1. In a directory-based sharding system, at step 3 the Shard Lookup Service receives a request for user ID 12345. What happens next?
easy
A. The service queries a centralized directory to find the exact shard assigned to user ID 12345
B. The service uses range boundaries to determine the shard for user ID 12345
C. The service forwards the request to all shards to find user ID 12345
D. The service hashes the user ID and routes to a shard based on the hash modulo shard count

Solution

  1. Step 1: Understand directory-based sharding

    Directory-based sharding uses a centralized mapping from keys to shards.

  2. Step 2: Trace step 3 action

    The Shard Lookup Service consults the directory to find the exact shard for user ID 12345.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Directory lookup returns shard for specific key [check]
Hint: Directory sharding uses centralized map to find shard [check]
Common Mistakes:
2. In a system where messages are produced to Kafka and consumed by a delivery worker, at step 4 the Delivery Worker reads the message offset from Kafka. What state does the Delivery Worker mark if the downstream consumer acknowledges receipt?
easy
A. Marks the message as sent but does not commit the offset yet
B. Deletes the message from Kafka immediately
C. Marks the message as delivered and commits the offset to Kafka
D. Retries sending the message regardless of acknowledgment

Solution

  1. Step 1: Understand Kafka offset commit semantics

    Kafka consumers commit offsets only after processing messages successfully to avoid reprocessing.

  2. Step 2: Delivery Worker behavior on acknowledgment

    Upon downstream acknowledgment, the worker marks the message as delivered and commits the offset, signaling safe processing.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Offset commit after acknowledgment ensures exactly-once processing [check]
Hint: Commit Kafka offset only after downstream ack to avoid duplicates [check]
Common Mistakes:
3. If the Kafka cluster responsible for location update ingestion becomes unavailable, what is the immediate failure observed in the system?
medium
A. Location updates queue up in the WebSocket Server memory until Kafka recovers
B. WebSocket Server blocks on sending updates, causing client-side UI to freeze
C. Location updates are lost silently without any retry or backpressure
D. Clients receive stale location data but no error is shown

Solution

  1. Step 1: Understand Kafka's role in ingestion

    Kafka decouples ingestion; if unavailable, producers (WebSocket Server) cannot push messages.

  2. Step 2: Trace failure impact

    WebSocket Server buffers updates temporarily but memory is limited; blocking would cause backpressure but usually async buffers exist.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka outage causes buffering, not silent loss or blocking immediately [check]
Hint: Kafka outage -> WebSocket buffers updates temporarily [check]
Common Mistakes:
4. For a large-scale web crawler, which architecture best balances crawl rate and politeness when crawling millions of domains with varying rate limits?
medium
A. Centralized Scheduler with a global queue and a single Politeness Policy enforcer
B. Distributed Scheduler with domain-based sharding and local Politeness Policy enforcement per shard
C. Multiple independent crawlers each with their own Scheduler and no shared Politeness Policy
D. Single-threaded crawler with a priority queue sorted by domain crawl time

Solution

  1. Step 1: Analyze centralized vs distributed scheduling

    Centralized Scheduler becomes a bottleneck at scale; distributed sharding allows parallelism and localized politeness enforcement.

  2. Step 2: Evaluate other options

    Independent crawlers without shared politeness risk domain overload; single-threaded crawler can't scale to millions of domains.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Distributed sharding enables scalable politeness enforcement [check]
Hint: Distributed sharding scales politeness enforcement best [OK]
Common Mistakes:
5. If the metadata update Kafka topic is unavailable, what exactly breaks in the playlist update flow?
medium
A. Playlist updates are lost silently with no retry or user notification
B. Playlist updates block on client until Kafka recovers, causing UI freeze
C. Playlist updates queue locally but never sync to other devices
D. Users see stale playlists but can still play songs offline

Solution

  1. Step 1: Role of Kafka in playlist updates

    Kafka asynchronously logs playlist metadata changes for durability and fan-out.

  2. Step 2: Failure impact if Kafka unavailable

    Without Kafka, updates sent to it are lost silently as no retry or buffering is implemented; UI does not block (B) because updates are async; local queuing (D) is not implemented; offline play (A) unaffected.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka down -> updates lost silently, no retry [check]
Hint: Kafka down means silent loss of playlist updates [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