Bird
Raised Fist0

Cache Eviction Policies - LRU, LFU, TTL, ARC and When to Use Each

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

Send cache write request

Client issues a SET command to cache key with value

Protocol:WebSocket
BeforeClient has new data to cache but not yet sent
AfterWrite request sent to Cache Write Frontend
Cache Write Frontend

Process write and forward to cache

Receives SET request, forwards to Redis cluster

Protocol:Redis SET
BeforeWrite request received from client
AfterData stored in Distributed Cache Cluster
Distributed Cache Cluster (Redis + Custom Eviction)

Store data and trigger eviction check

Stores key-value, triggers eviction policy evaluation

Protocol:Internal RPC
BeforeCache has new key stored, memory usage increased
AfterEviction Policy Manager notified to evaluate eviction
Eviction Policy Manager

Evaluate eviction policy

Runs LRU, LFU, TTL, ARC algorithms to decide evictions

Protocol:RPC Call
BeforeCache memory usage near limit, eviction needed
AfterKeys selected for eviction and eviction commands sent
Metrics & Monitoring

Record eviction and cache metrics

Receives metrics push about eviction decisions and cache stats

Protocol:Metrics Push
BeforeEviction decisions completed, cache state updated
AfterMetrics stored for monitoring and tuning
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Client Applications │
└─────────────┬─────────┘
              │ WebSocket
              ▼
┌───────────────────────┐
│   Cache Write Frontend│
└─────────────┬─────────┘
              │ Redis SET
              ▼
┌───────────────────────────────────────────────┐
│ Distributed Cache Cluster                      │
│ (Redis + Custom Eviction)                      │
└─────────────┬─────────────────────────────────┘
              │ RPC Call
              ▼
┌───────────────────────────────┐
│ Eviction Policy Manager        │
│ (LRU, LFU, TTL, ARC decisions)│
└─────────────┬─────────────────┘
              │ Metrics Push
              ▼
┌───────────────────────┐
│ Metrics & Monitoring   │
└───────────────────────┘
Design Rationale

This architecture shows a cache write request flowing from Client Applications through the Cache Write Frontend to the Distributed Cache Cluster, which uses Redis with custom eviction logic. The Eviction Policy Manager evaluates multiple policies like LRU, LFU, TTL, and ARC to decide which keys to evict when memory limits are approached. Metrics & Monitoring collects data on eviction decisions and cache usage to enable tuning and alerting. This design cleanly separates client interaction, cache storage, eviction logic, and monitoring, allowing flexible policy management and observability.

Primary Focus

✓

Practice

(1/5)
1. A SaaS platform must ensure strict data isolation between tenants while allowing shared infrastructure. Which component best enforces tenant data isolation at the storage layer?
easy
A. Use a single shared database schema with tenant_id column filtering in application code
B. Use separate database instances per tenant with network-level access controls
C. Use a multi-tenant database with row-level security policies enforced by the DBMS
D. Use a caching layer to segregate tenant data in memory for faster isolation

Solution

  1. Step 1: Understand tenant isolation requirements

    Strict isolation requires preventing any data leakage between tenants, which network-level controls and separate DB instances provide.

  2. Step 2: Evaluate options for isolation guarantees

    Use a single shared database schema with tenant_id column filtering in application code relies on application filtering, prone to bugs; Use a multi-tenant database with row-level security policies enforced by the DBMS depends on DBMS features that may be complex and less secure; Use a caching layer to segregate tenant data in memory for faster isolation only caches data and doesn't guarantee persistent isolation.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Separate DB instances + network controls -> strongest tenant isolation [check]
Hint: Separate DB instances isolate tenants physically [check]
Common Mistakes:
2. For a proximity service requiring low-latency queries and frequent updates of business locations, which spatial indexing approach is better and why?
medium
A. Use Geohash-based indexing because it supports efficient prefix queries and simpler updates
B. Use a full R-tree index because it guarantees minimal overlap and tight bounding rectangles
C. Use a grid-based fixed cell index because it provides exact bounding box queries without hierarchy
D. Use a Quadtree because it supports fast insertions and deletions with balanced trees

Solution

  1. Step 1: Compare update and query costs

    Quadtree (Use a Quadtree because it supports fast insertions and deletions with balanced trees) can become unbalanced and expensive to update frequently. R-tree (Use a full R-tree index because it guarantees minimal overlap and tight bounding rectangles) is complex and costly to maintain with frequent writes.

  2. Step 2: Evaluate Geohash benefits

    Geohash (Use Geohash-based indexing because it supports efficient prefix queries and simpler updates) encodes locations into fixed-length strings allowing efficient prefix queries and simpler incremental updates, ideal for low-latency and frequent writes.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Geohash supports efficient prefix queries and simpler updates [check]
Hint: Geohash enables fast prefix queries and simpler frequent updates [OK]
Common Mistakes:
3. If the reverse proxy responsible for SSL termination crashes, what exactly breaks in the request flow?
medium
A. Clients can still connect directly to backend servers without interruption
B. Clients' SSL handshakes fail, so connections never reach backend servers
C. Backend servers receive unencrypted traffic, exposing internal data
D. The reverse proxy forwards requests without decrypting, causing backend errors

Solution

  1. Step 1: Understand reverse proxy SSL termination failure

    If the reverse proxy crashes, SSL termination stops, so backend servers receive unencrypted traffic if clients connect directly or fallback occurs.

  2. Step 2: Eliminate other options

    Clients cannot connect directly if proxy is mandatory; SSL handshake fails only if proxy blocks connection; proxy can't forward encrypted requests without decrypting if crashed.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Reverse proxy crash exposes backend to unencrypted traffic [check]
Hint: Reverse proxy crash exposes backend to unencrypted traffic [check]
Common Mistakes:
4. At 10x scale, which component in the code repository system is most likely to become the bottleneck first, and why?
hard
A. The branch metadata store, because it is a centralized stateful service with high write contention
B. The merge service, because merge conflict resolution requires CPU-intensive three-way diffs
C. The object storage cluster, because storing large blobs grows linearly with commits
D. The pull request notification system, because fan-out to millions of users overwhelms messaging queues

Solution

  1. Step 1: Identify bottleneck candidates at 10x scale

    Branch metadata store handles all branch pointer updates; centralized and stateful, it faces high write contention.

  2. Step 2: Compare other components

    Object storage scales horizontally; merge service CPU load is distributed; notification system can be sharded and throttled.

  3. Step 3: Conclude bottleneck

    Branch metadata store's centralized writes limit throughput and cause latency spikes first.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Centralized branch metadata store -> write contention bottleneck [check]
Hint: Centralized metadata store hits write contention first [check]
Common Mistakes:
5. At 10x scale, which component is most likely to fail first due to the exact lookup requirement, and why?
hard
A. The backend database, because it cannot handle the increased exact lookup queries without Bloom filter filtering
B. The network layer, because increased traffic from exact lookups saturates bandwidth
C. The Bloom filter component, because its false positive rate grows linearly with scale, causing excessive backend queries
D. The cache layer, because it cannot store all keys for exact lookups at 10x scale

Solution

  1. Step 1: Understand Bloom filter scaling behavior

    Bloom filter false positive rate increases with scale unless filter size grows proportionally, causing more backend queries.

  2. Step 2: Analyze component failure likelihood

    Backend (A) fails eventually but Bloom filter inefficiency causes overload first. Network (C) and cache (D) are bottlenecks but secondary to Bloom filter false positive explosion.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Bloom filter false positives grow with scale, triggering backend overload first [check]
Hint: Bloom filter false positives grow with scale, overload backend first [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