Bird
Raised Fist0

Why Caching Exists and the Real Cost of Not Caching

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

Receives client request

API Gateway accepts HTTP request and prepares to check cache

Protocol:HTTP
BeforeClient request just arrived at API Gateway
AfterAPI Gateway forwards request to Redis Cache Cluster
Redis Cache Cluster

Checks for cached data

Redis GET executed to find requested data

Protocol:Redis GET
BeforeRequest data not yet checked in cache
AfterCache miss detected; no data found in Redis
Cassandra Primary Store

Queries persistent store

CQL query executed to retrieve data from Cassandra

Protocol:CQL Query
BeforeCache miss confirmed; data not in Redis
AfterData retrieved from Cassandra Primary Store
Cache Invalidation Service

Updates cache with fresh data

Sends invalidation event to update Redis Cache

Protocol:Invalidation Event
BeforeCache contains stale or no data for request
AfterCache updated with fresh data from Cassandra
Monitoring & Metrics

Records cache miss and latency metrics

Logs cache miss event and increased latency

Protocol:Internal Metrics
BeforeCache miss and data retrieval completed
AfterMetrics updated to reflect cache miss cost
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│    API Gateway    │
└─────────┬─────────┘
          │ HTTP Request
          ▼
┌───────────────────────┐
│  Redis Cache Cluster   │
└─────────┬─────────────┘
          │ Redis GET
          ▼
┌───────────────────────────┐
│ Cassandra Primary Store    │
└─────────┬─────────────────┘
          │ CQL Query
          ▼
┌───────────────────────────────┐
│ Cache Invalidation Service     │
└─────────┬─────────────────────┘
          │ Invalidation Event
          ▼
┌───────────────────────┐
│ Monitoring & Metrics   │
└───────────────────────┘
Design Rationale

This architecture diagram illustrates why caching exists and the real cost of not caching. The API Gateway receives a client request and first queries the Redis Cache Cluster for data. On a cache miss, the request falls back to the Cassandra Primary Store, which is slower due to disk access and distributed queries. After retrieving fresh data, the Cache Invalidation Service updates Redis to keep cache consistent. Monitoring & Metrics tracks cache misses and latency, highlighting the performance penalty when caching fails. This flow shows how caching reduces load on the primary store and improves response times, while cache misses cause increased latency and system load.

Primary Focus

✓

Practice

(1/5)
1. A payment gateway must reliably process millions of payment requests per second and ensure durability despite transient failures. Which component is best suited to decouple the payment request ingestion from downstream processing to achieve this?
easy
A. Use a distributed log system like Kafka to persist and stream payment events
B. Use an in-memory cache like Redis to queue payment requests for fast access
C. Use a relational database with auto-increment IDs to store payment requests synchronously
D. Use a REST API gateway that directly calls payment processors synchronously

Solution

  1. Step 1: Identify the role of the decoupling component

    The component must provide durability and handle high throughput without blocking the ingestion path.

  2. Step 2: Evaluate Kafka's suitability

    Kafka provides a distributed, durable log with partitioning and replication, enabling asynchronous processing and replay.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka decouples ingestion and processing with durability and scale [check]
Hint: Durable logs decouple ingestion from processing [check]
Common Mistakes:
2. In the request flow of a Redis-based centralized rate limiter, at Step 3 the API server performs an atomic INCR on the Redis key. What is the state of the counter immediately after this step if the limit is exceeded?
easy
A. The counter is reset to zero and the request is allowed
B. The counter value is incremented but the request is rejected
C. The counter value remains unchanged and the request is queued
D. The counter is decremented to rollback the increment and the request is allowed

Solution

  1. Step 1: Trace the atomic INCR operation

    At Step 3, the Redis INCR command increments the counter regardless of limit.

  2. Step 2: Check limit enforcement logic

    If the incremented counter exceeds the limit, the request is rejected but the counter remains incremented to reflect the attempt.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Counter increments atomically; request rejected if limit exceeded [check]
Hint: Counter increments first, then limit check rejects request [check]
Common Mistakes:
3. At 10x scale, which component in the distributed API rate limiter is most likely to fail first and why?
hard
A. Centralized logging service, because it cannot handle the increased write volume
B. API gateway, because it cannot maintain connections for all clients simultaneously
C. Distributed Counter cluster, because sharding limits cause hot partitions for popular users
D. Edge caches, because their local memory limits prevent storing counters for all users

Solution

  1. Step 1: Analyze component scalability

    Edge caches store counters in memory per user; memory is limited and grows with user count.

  2. Step 2: Compare bottlenecks

    Logging (A) can be scaled with partitioning; Distributed Counter (C) sharding mitigates hot spots; API gateway (D) scales horizontally. Edge caches (B) hit memory limits first, causing eviction or failures.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Edge caches fail first due to fixed local memory limits [check]
Hint: Edge caches limited by memory, fail before scalable components [check]
Common Mistakes:
4. At 10x scale, which component in a graph database system handling real-time relationship queries is most likely to fail first, and why?
hard
A. The query planner, because it cannot optimize complex traversals at scale
B. The relationship index, because it becomes a hotspot and cannot shard efficiently
C. The storage engine, because disk I/O saturates under high write volume
D. The network layer, because increased traffic causes packet loss and retransmissions

Solution

  1. Step 1: Identify bottleneck at scale

    Relationship indexes are critical for traversal and often stored as centralized or partially sharded structures.

  2. Step 2: Sharding challenge

    Relationship indexes are hard to shard due to cross-node edges, causing hotspots and contention under 10x load.

  3. Step 3: Compare other components

    Storage engines can scale with hardware; query planners optimize but are less likely first bottleneck; network issues are secondary.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    Relationship index hotspots cause first failure at 10x scale [check]
Hint: Relationship index hotspots break first at scale [check]
Common Mistakes:
5. At 10x scale, which component in the SLO error budget tracking system is most likely to become the bottleneck first, and why?
hard
A. The metrics aggregation service, because it maintains stateful counters and cannot shard error budget calculations easily
B. The dashboard visualization layer, because rendering 10x more data overwhelms client browsers
C. The raw event ingestion pipeline, because Kafka partitions can be increased indefinitely without limit
D. The alerting system, because it can batch alerts and scale horizontally without state

Solution

  1. Step 1: Identify stateful components that limit horizontal scaling

    The metrics aggregation service maintains counters and error budget state, which are hard to shard without losing accuracy.

  2. Step 2: Evaluate other components' scalability

    Dashboards (A) are client-side and less critical; Kafka (C) scales well with partitions; alerting (D) can batch and scale horizontally.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful aggregation -> sharding limits -> bottleneck at scale [check]
Hint: Stateful aggregation limits sharding, causing first bottleneck at scale [OK]
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