Bird
Raised Fist0

Why NoSQL Exists and When SQL is the Wrong Tool

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

Receives user write request

API Gateway accepts HTTP POST with new data payload

Protocol:HTTP/REST
BeforeUser data exists only on client device
AfterData is accepted and forwarded to Kafka Cluster
Kafka Cluster

Appends write request to partitioned log

Kafka stores message with partition key for ordering and durability

Protocol:Kafka
BeforeWrite request received from API Gateway
AfterWrite request durably stored in Kafka log; ready for consumers
Cassandra DB

Consumes Kafka log and writes data

Cassandra writes data asynchronously with tunable consistency

Protocol:CQL
BeforeWrite request present in Kafka log
AfterData persisted in Cassandra with eventual consistency across replicas
Redis Cache

Caches recent write for fast read access

Redis SET updates cache with new data for low-latency reads

Protocol:Redis SET
BeforeData persisted in Cassandra but not yet cached
AfterData available in Redis cache for quick retrieval
Replication & Multi-Region Sync

Synchronizes data across regions

Replicates Cassandra data asynchronously to other regions

Protocol:Custom replication protocol
BeforeData stored in primary region Cassandra cluster
AfterData replicated to secondary regions ensuring global availability
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP/REST
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka
        ▼
┌───────────────┐
│ Cassandra DB  │
└───────┬───────┘
        │ CQL
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ Redis GET/SET
        ▼
┌───────────────────────────────┐
│ Replication & Multi-Region Sync│
└───────────────────────────────┘
Design Rationale

This architecture demonstrates why NoSQL databases like Cassandra exist and when SQL is the wrong tool. The API Gateway handles incoming requests and pushes them into Kafka, a distributed log that ensures ordered, durable writes at high throughput. Cassandra consumes Kafka logs to persist data with eventual consistency, optimized for multi-region replication and high write volumes. Redis Cache provides low-latency reads by caching hot data, reducing load on Cassandra. The Replication & Multi-Region Sync component asynchronously replicates data across regions to maintain availability and fault tolerance. This design avoids relational databases that struggle with horizontal scaling and write-heavy workloads, illustrating the trade-offs that led to NoSQL adoption.

Primary Focus

✓

Practice

(1/5)
1. If the message queue (Kafka) is unavailable during the flash sale, what exactly breaks in the order processing pipeline?
medium
A. Payment service retries indefinitely, causing duplicate charges
B. Order requests block at the API layer, causing client timeouts and lost orders
C. Orders are accepted but payment processing is delayed indefinitely
D. Orders are accepted but inventory updates are lost, causing overselling

Solution

  1. Step 1: Trace Kafka's role in order processing

    Kafka decouples order acceptance from inventory update; if Kafka is down, inventory update messages are lost or not sent.

  2. Step 2: Analyze failure impact

    API layer (B) uses async calls, so requests don't block. Payment retries (D) are independent. Accepting orders without inventory update (C) causes overselling.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka down -> inventory updates lost -> overselling risk [check]
Hint: Kafka outage loses inventory updates causing overselling [check]
Common Mistakes:
2. For billing in a multi-tenant SaaS platform, which architecture best supports accurate usage tracking with minimal latency impact on tenant requests?
medium
A. Asynchronous event-driven usage aggregation via a message queue and batch processing
B. Embedding billing logic directly in the tenant service to update counters in-memory
C. Periodic polling of tenant usage logs by the billing service every hour
D. Synchronous billing updates on every tenant API call to the billing database

Solution

  1. Step 1: Analyze latency and accuracy trade-offs

    Synchronous updates (Synchronous billing updates on every tenant API call to the billing database) add latency; polling (Periodic polling of tenant usage logs by the billing service every hour) delays billing data; in-memory counters (Embedding billing logic directly in the tenant service to update counters in-memory) risk data loss.

  2. Step 2: Evaluate asynchronous event-driven approach

    Asynchronous event-driven usage aggregation via a message queue and batch processing decouples billing from tenant requests, ensuring accurate aggregation with minimal latency impact.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Event-driven async billing -> accurate, low-latency tenant requests [check]
Hint: Async event-driven billing decouples latency [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. If the idempotency key store becomes unavailable, what is the most likely failure mode for the payment API when a client retries a payment request?
medium
A. The payment API processes each retry as a new payment, causing duplicate charges
B. The payment API queues requests until the store recovers, delaying all payments
C. The payment API rejects all requests with 503 Service Unavailable errors
D. The payment API returns cached responses from a fallback in-memory store

Solution

  1. Step 1: Understand idempotency store role in retries

    Without the store, the API cannot verify if a request is a retry, so it must delay processing to avoid duplicates.

  2. Step 2: Eliminate other options

    Rejecting all requests is possible but not typical; processing retries as new causes duplicates, which is avoided; fallback caches are uncommon and inconsistent.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Unavailable idempotency store causes request queuing to prevent duplicates [check]
Hint: No idempotency store -> queue retries to avoid duplicates [check]
Common Mistakes:
5. If the API Gateway's rate limiting cache fails and is not replaced, what is the immediate failure mode observed by users?
medium
A. Users receive explicit rate limit errors even when under limit
B. Requests bypass rate limiting, causing backend overload and degraded service
C. The system automatically switches to database-level rate limiting with no impact
D. All requests are silently dropped without response

Solution

  1. Step 1: Understand cache failure impact

    Without the cache, the API Gateway cannot track usage accurately, often defaulting to conservative rate limit errors to protect backend.

  2. Step 2: Evaluate other options

    Silent drops cause user confusion; bypassing limits risks overload; automatic fallback to DB rate limiting is rare and slow.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Cache failure -> conservative rate limit errors -> user impact [check]
Hint: Cache failure triggers conservative rate limit errors [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