Bird
Raised Fist0

Cache Invalidation Strategies - TTL, Purge, Surrogate Keys

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

Receives cache invalidation request

Client sends HTTP POST to invalidate cache key or surrogate key

Protocol:HTTP POST
BeforeNo invalidation request received yet
AfterInvalidation request accepted and ready to publish
Kafka Invalidation Topic

Stores invalidation event

API Gateway publishes invalidation event to Kafka topic

Protocol:Kafka Publish
BeforeInvalidation event not yet persisted
AfterInvalidation event durably stored in Kafka
Invalidation Processor

Consumes invalidation event

Processor reads event from Kafka and decides invalidation method

Protocol:Kafka Consume
BeforeInvalidation event pending processing
AfterInvalidation event acknowledged and processing started
Redis Cluster

Executes cache invalidation

Processor issues Redis DEL or SET with TTL commands to invalidate keys

Protocol:Redis DEL / SET
BeforeCache entries exist for keys to invalidate
AfterCache entries deleted or TTL updated to expire soon
CDN Edge Nodes

Purges cached content by surrogate keys

Processor sends surrogate key purge commands to CDN edges

Protocol:CDN Surrogate-Key Purge
BeforeCDN edges have cached content with surrogate keys
AfterCDN edges purge cached content matching surrogate keys
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│ Cache Inval. API Gateway       │
└───────────────┬───────────────┘
                │ HTTP POST /invalidate
                ▼
┌───────────────────────────────┐
│ Kafka Inval. Topic             │
└───────────────┬───────────────┘
                │ Kafka Publish
                ▼
┌───────────────────────────────┐
│ Invalidation Processor         │
└───────────────┬───────────────┘
                │ Redis DEL / SET with TTL
                ▼
┌───────────────────────────────┐
│ Redis Cluster                  │
└───────────────┬───────────────┘
                │ Surrogate-Key purge cmd
                ▼
┌───────────────────────────────┐
│ CDN Edge Nodes                 │
└───────────────────────────────┘
Design Rationale

This architecture illustrates cache invalidation using three strategies: TTL, purge, and surrogate keys. The Cache Invalidation API Gateway receives requests and publishes them to a Kafka topic, ensuring durability and decoupling. The Invalidation Processor consumes these events and performs cache invalidation on Redis by deleting keys or setting TTLs to expire entries. For CDN edge caches, it issues surrogate key purge commands to efficiently invalidate grouped content. This design balances reliability, scalability, and flexibility by leveraging Kafka for event durability and Redis plus CDN for fast cache updates.

Primary Focus

✓

Practice

(1/5)
1. For a system requiring minimal latency on shard lookup and dynamic shard scaling, which architecture is best suited?
medium
A. Distributed consistent hashing with local hash ring replicas updated asynchronously
B. Centralized shard mapping service queried synchronously on every request
C. Client-side static shard mapping with manual updates on shard changes
D. Range-based partitioning with a global metadata service for shard boundaries

Solution

  1. Step 1: Evaluate latency and scaling constraints

    Centralized service (Centralized shard mapping service queried synchronously on every request) adds latency and single point of failure; client-side static mapping (Client-side static shard mapping with manual updates on shard changes) is inflexible and error-prone; range partitioning (Range-based partitioning with a global metadata service for shard boundaries) struggles with hotspots and dynamic scaling.

  2. Step 2: Assess distributed consistent hashing

    Distributed consistent hashing with local replicas (Distributed consistent hashing with local hash ring replicas updated asynchronously) provides low-latency shard lookup and supports dynamic shard scaling with minimal coordination.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Local hash ring replicas enable fast, scalable shard lookup [check]
Hint: Local hash ring replicas enable fast, scalable shard lookup [OK]
Common Mistakes:
2. If the artifact registry becomes unavailable during deployment, what is the most likely failure mode in the CI/CD pipeline?
medium
A. Deployment proceeds with cached artifacts, risking inconsistent versions
B. Deployment triggers rollback immediately without attempting deployment
C. Deployment blocks waiting for artifact registry recovery, causing pipeline timeout
D. Deployment skips artifact validation and proceeds, risking corrupted deployments

Solution

  1. Step 1: Trace deployment behavior on artifact registry unavailability

    Deployment cannot validate or fetch artifacts, so it aborts and triggers rollback to maintain safety.

  2. Step 2: Eliminate other failure modes

    Proceeding with cached or skipping validation risks corrupted deployments; blocking indefinitely causes pipeline stalls but rollback is preferred.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Unavailable registry -> deployment aborts and triggers rollback [check]
Hint: No artifact registry -> abort deployment, rollback triggered [check]
Common Mistakes:
3. If the Market Data Feed component crashes and stops publishing updates, what is the exact failure observed by external clients subscribing to real-time stock prices?
medium
A. Clients receive stale prices indefinitely with no indication of failure
B. Clients receive partial updates but with delayed timestamps causing confusion
C. Clients receive an error message and automatic reconnection attempts begin
D. Clients continue receiving cached data from the Matching Engine without updates

Solution

  1. Step 1: Understand Market Data Feed failure impact

    When Market Data Feed crashes, it stops pushing updates; clients detect connection loss and receive error events triggering reconnection.

  2. Step 2: Eliminate other options

    Clients receive stale prices indefinitely with no indication of failure is wrong because clients detect connection loss; Clients receive partial updates but with delayed timestamps causing confusion is wrong because partial updates don't occur without feed; Clients continue receiving cached data from the Matching Engine without updates is wrong because Matching Engine doesn't serve cached market data.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Feed crash -> clients get error + reconnect attempts [check]
Hint: Feed crash triggers client error and reconnect [check]
Common Mistakes:
4. For a globally distributed collaborative editor with many offline users, which approach better supports eventual consistency and offline edits, and why?
medium
A. Use Operational Transformation (OT) because it requires a central server to order operations
B. Use a relational database with strict locking to serialize all edits globally
C. Use CRDTs because they allow local operations to be merged without coordination and support offline edits
D. Use a message queue with timestamp ordering to ensure global operation order

Solution

  1. Step 1: Compare OT and CRDT for offline and distributed scenarios

    OT typically requires a central server to order and transform operations, making offline support complex.

  2. Step 2: Understand CRDT advantages

    CRDTs are designed for decentralized environments, allowing local operations to be merged eventually without coordination, ideal for offline edits and global distribution.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CRDTs enable offline edits and eventual consistency without central coordination [check]
Hint: CRDTs merge offline edits without central coordination [OK]
Common Mistakes:
5. If the Geohash prefix index is unavailable, what exactly breaks in the nearby search flow?
medium
A. The system falls back to a full scan of all businesses, causing high latency but correct results
B. The system crashes because no fallback spatial index exists
C. Nearby search queries return incomplete results because spatial bucketing is missing, causing false negatives
D. The system returns all businesses regardless of location, causing false positives but no misses

Solution

  1. Step 1: Understand Geohash prefix role

    Geohash prefix index buckets locations; without it, filtering by location is impossible.

  2. Step 2: Trace failure impact

    Without the prefix index, the system cannot filter by location, so it returns all businesses (false positives), not incomplete results (false negatives).

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Missing Geohash prefix index causes unfiltered results (false positives) [check]
Hint: No Geohash prefix -> no filtering -> all results returned [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