Core Code
Core Code Modern Dev Handbook
SYSTEM-DESIGN Contents
Constraints & Core Metrics
What Is System Design (Production-First) Functional vs Non-Functional Requirements Constraints, Assumptions, and Design Inputs Latency vs Throughput Tail Latency (p95/p99) and Why It Dominates UX SLI, SLO, SLA: The Reliability Contract Capacity Estimation Basics Bottlenecks and Queues (Little's Law Intuition)
Scaling & Traffic Management
Vertical vs Horizontal Scaling Load Balancing Fundamentals Caching Strategies Overview Cache Invalidation and Consistency Rate Limiting at Scale Backpressure: Preventing Overload Timeouts and Retries (Safe Defaults) Graceful Degradation and Traffic Shedding
Data & Consistency
Database Scaling Basics Replication: Read Replicas and Failover Consistency Models (Strong vs Eventual) Sharding Basics Partitioning and Hotspot Avoidance Idempotency and Deduplication Eventual Consistency and UX Schema Evolution and Backward Compatibility
Reliability Patterns
Timeouts: Bounding Damage Retry Strategies (Jitter, Caps, Budgets) Circuit Breaker Bulkhead Pattern Fallbacks and Graceful Degradation Load Shedding and Admission Control Backups and Restore Strategy Disaster Recovery (RPO/RTO)
Observability & Control
Golden Signals: Latency, Traffic, Errors, Saturation Metrics: SLIs and SLO Targets Logging at Scale (Structure and Cost) Correlation IDs and Context Propagation Distributed Tracing Overview Alerting and Runbooks Capacity Planning and Saturation Postmortems and Continuous Improvement
Case Studies
Case Study: URL Shortener Case Study: File Upload and Serving Case Study: Notification System Case Study: Chat System Overview Case Study: Rate Limiter Service Case Study: Social Feed (Fan-out Trade-offs) Case Study: Search Autocomplete Case Study: Analytics Ingestion Pipeline
Distributed Systems Foundations
CAP Theorem Consensus Basics Leader Election Distributed Locking Clock Skew Split Brain Quorum Reads and Writes Eventual vs Strong Consistency (Practical)
Service Communication Patterns
Synchronous vs Asynchronous Request-Response Pattern Message Queues Pub/Sub Pattern Event-Driven Architecture Saga Pattern CQRS Overview Outbox Pattern API Gateway Pattern Backend For Frontend (BFF)
Data at Scale Advanced
Index Design Deep Dive Query Planning Multi-Region Databases Read-After-Write Guarantees Global Databases Data Locality Large Table Strategies Background Jobs Design
Multi-Region Architecture
Multi-Region Basics Active-Active Active-Passive Geo DNS Cross-Region Replication Global Latency Optimization Regional Failover
Cost-Aware System Design
Cost vs Performance Storage Cost Trade-offs Cache Cost Analysis Overprovisioning vs Risk Cloud Pricing Mental Model Right-Sizing Instances
Security Architecture
Zero Trust Service-to-Service Auth Secrets Management Encryption at Rest Encryption in Transit DDoS Protection Multi-Tenant Data Isolation
System Design Interview
Design Twitter Design YouTube Design Uber Design Payment System Design E-commerce Platform Design Distributed Cache

Cache Invalidation and Consistency

Invalidation is the hardest part: choose TTLs, versioning, or event-driven invalidation based on correctness requirements and failure modes.
On this page

Why Invalidation Is Hard

Caching breaks the default guarantee that reads reflect the latest write. Invalidation is hard because updates can happen from multiple paths, failures can interrupt invalidation, and distributed systems do not give you perfect ordering for free.

Three Common Approaches

  • TTL-based: expire after a duration; simplest, but serves stale data until expiry.
  • Write-through / write-around: update cache on writes or bypass cache on writes; reduces staleness but adds complexity.
  • Event-driven invalidation: publish events to invalidate affected keys; fast correctness, but requires reliable delivery and idempotency.

Choose Based on Correctness Needs

Not all data requires strong freshness. Define freshness requirements per endpoint. For user-visible reads, seconds of staleness may be acceptable. For billing or permissions, it may not be.

Versioned Keys

Versioning is a practical invalidation technique: instead of deleting keys, you change the key version when the underlying data changes. This avoids races where old invalidations arrive late.

Example:
user:123:v1
When user profile changes -> bump to v2
user:123:v2

Multi-Key and Fan-Out Problems

Some writes affect many cached reads: updating a post can affect feeds, search indexes, and aggregates. Production-first systems avoid invalidating thousands of keys synchronously in the write path. They prefer background workers, event-driven refresh, or bounded invalidation strategies.

Failure Modes You Must Plan For

  • Cache is down: does your app fail open (go to DB) or fail closed?
  • Invalidation fails: how long can stale data persist?
  • Replication lag: read replicas may be behind writes, compounding staleness.

Production-First Takeaway

Pick the simplest invalidation strategy that meets correctness requirements. Use TTLs for low-risk data, versioned keys to avoid races, and event-driven invalidation when freshness is critical and you can operate the pipeline reliably.

Rate Limiting at Scale →