7a:T6cf,In the hierarchy of distributed systems components, **caching** occupies a unique position: it is simultaneously one of the simplest concepts to explain and one of the most challenging to implement correctly at scale. The premise is deceptively simple—store frequently accessed data closer to the application to avoid repeated expensive operations. Yet the engineering reality of building a cache that serves millions of requests per second with sub-millisecond latency, maintains consistency across distributed nodes, handles failures gracefully, and scales horizontally while remaining cost-effective is anything but simple. Every major technology company—Google, Facebook, Amazon, Netflix, Twitter—has invested heavily in building or customizing distributed caching infrastructure. These systems sit at the critical path of nearly every user interaction, and their performance characteristics directly impact user experience, system throughput, and infrastructure costs. A well-designed distributed cache can reduce database load by 99%, cut response times from hundreds of milliseconds to single-digit milliseconds, and enable applications to scale horizontally without proportional increases in backend infrastructure. Before we can design such a system, we must establish clear requirements. In system design interviews and real-world engineering alike, the requirements phase isn't merely a formality—it's the foundation upon which all architectural decisions rest. A cache designed for session storage has fundamentally different requirements than one optimized for API response caching or content delivery. This page establishes the complete requirements framework for building a production-grade distributed caching system.7b:T486,To properly scope our distributed cache design, we must first understand why caching is necessary and what problems it solves. Caching exists because of a fundamental asymmetry in computing: **some operations are expensive, and their results are needed repeatedly**. **The Latency Hierarchy** Modern systems exhibit dramatic differences in access latency across different storage tiers: - **L1 CPU Cache**: ~0.5 nanoseconds - **L2 CPU Cache**: ~7 nanoseconds - **Main Memory (RAM)**: ~100 nanoseconds - **SSD Read**: ~150 microseconds (150,000 ns) - **Network Round-Trip (Same Data Center)**: ~500 microseconds (500,000 ns) - **HDD Seek**: ~10 milliseconds (10,000,000 ns) - **Network Round-Trip (Cross-Region)**: ~150 milliseconds (150,000,000 ns) Notice the orders of magnitude between tiers. A single cross-region network round-trip is **300 million times slower** than an L1 cache hit. This latency hierarchy explains why caching at every layer of the stack is essential for performance-critical systems. **What Makes an Operation Cache-Worthy?** Not all data benefits equally from caching. The ideal cache candidates exhibit these characteristics:7c:T41e,# Object storage unique_objects = 1_000_000_000 # 1 billion unique objects avg_object_size = 1024 # 1 KB avg_key_size = 100 # bytes # Raw data size raw_data_size = unique_objects * (avg_object_size + avg_key_size) raw_data_size_tb = raw_data_size / (1024 ** 4) print(f"Raw data size: {raw_data_size_tb:.2f} TB") # Memory overhead (hash table, pointers, TTL metadata) # Typically 50-100% overhead for in-memory data structures overhead_multiplier = 1.75 total_memory = raw_data_size * overhead_multiplier total_memory_tb = total_memory / (1024 ** 4) print(f"Total memory with overhead: {total_memory_tb:.2f} TB") # Node sizing memory_per_node_gb = 256 # Common for cache-optimized instances memory_per_node_bytes = memory_per_node_gb * (1024 ** 3) nodes_required = total_memory / memory_per_node_bytes print(f"Nodes required (256 GB each): {nodes_required:.0f}") # Add replication factor (e.g., 2 for single replica) replication_factor = 2 total_nodes = nodes_required * replication_factor print(f"Total nodes with replication: {total_nodes:.0f}")72:{"json":{"id":"seed_ef1ed4adaa12d2bc2b472546527737cb","slug":"distributed-cache","category":"System Design (HLD)","topic":"Distributed Cache","title":"Designing a Distributed Cache","description":"Master the art of designing distributed caching systems that serve millions of requests with sub-millisecond latency. Learn cache partitioning, consistent hashing, eviction policies, cache coherence, and failure handling strategies used by systems like Redis, Memcached, and enterprise-grade caching infrastructure.","difficulty":"ADVANCED","estimatedMinutes":120,"pages":[{"id":"seed_2582ce2e81aa6b96db0fa702a775c571","title":"Requirements: Low-Latency Caching","order":0,"content":[{"id":"opening-context","title":"The Speed Imperative","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete functional and non-functional requirements for a distributed caching system, be able to perform capacity estimation for cache infrastructure, identify the key architectural constraints that shape cache design decisions, and recognize the trade-offs inherent in different caching approaches.","variant":"info"},"type":"callout"}]},{"id":"understanding-caching-problem","title":"Understanding the Caching Problem Space","content":[{"data":{"content":"$7b"},"type":"text"},{"data":{"items":["**High Read-to-Write Ratio** — Data that is read frequently but written infrequently. User profiles, product catalogs, configuration settings, and static content are classic examples. A 100:1 read-to-write ratio means each write operation amortizes across 100 cache hits.","**Expensive to Compute or Retrieve** — Operations involving complex database joins, external API calls, machine learning inference, or compute-intensive transformations. The cost of caching must be offset by the cost of regeneration.","**Temporal Locality** — Data accessed at one point in time is likely to be accessed again soon. User sessions, trending content, and recently viewed items exhibit strong temporal locality.","**Tolerance for Staleness** — Data where brief inconsistency doesn't cause correctness issues. A user seeing a slightly outdated follower count is acceptable; a user seeing an incorrect account balance is not.","**Size-Appropriate** — Data small enough that memory costs remain reasonable. Caching multi-megabyte objects consumes memory quickly and may not provide proportional benefits."],"title":{"icon":"Target","text":"Cache-Worthy Data Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The Caching Paradox**\n\nCaching introduces a fundamental tension: **the data closest to the user is also the most likely to be stale**. This paradox shapes every distributed cache design. We must balance proximity (for latency) against freshness (for correctness), and different applications strike this balance differently.\n\nA news feed can tolerate seconds of staleness without user impact. A stock trading platform cannot tolerate even milliseconds. A collaborative editing tool like Google Docs requires near-real-time consistency. Understanding where your application falls on this spectrum is the first requirement decision."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Cache Hit Rate: The North Star Metric","content":"The most important metric for any cache is the **hit rate**—the percentage of requests served from cache rather than the origin. A cache with a 99% hit rate reduces origin load by 100x. A cache with a 50% hit rate only reduces load by 2x. Every 1% improvement in hit rate at 99% is equivalent to 50% reduction in origin traffic. This is why cache optimization focuses intensely on marginal hit rate improvements.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"functional-requirements","title":"Functional Requirements","content":[{"data":{"content":"Functional requirements define **what** the system must do. For a distributed cache, these requirements encompass the core operations, data model, and features that clients expect.\n\n**Core Cache Operations**\n\nEvery distributed cache must support three fundamental operations:"},"type":"text"},{"data":{"rows":[["GET(key)","Retrieve value associated with key","Returns value if exists, null/miss otherwise","< 1ms p99"],["SET(key, value, ttl)","Store key-value pair with optional TTL","Overwrites existing; atomic operation","< 1ms p99"],["DELETE(key)","Remove key from cache","Idempotent; succeeds even if key absent","< 1ms p99"]],"caption":"Core Cache Operations","headers":["Operation","Description","Semantics","Expected Latency"]},"type":"table"},{"data":{"content":"**Extended Operations**\n\nProduction caches typically require additional operations beyond the basic three:"},"type":"text"},{"data":{"items":["**MGET(keys) / MSET(key-value pairs)** — Batch operations to reduce network round-trips. Getting 100 keys in one MGET is far more efficient than 100 individual GETs.","**INCREMENT(key, delta) / DECREMENT(key, delta)** — Atomic counter operations essential for rate limiting, view counts, and statistics aggregation.","**EXPIRE(key, ttl) / TTL(key)** — Manage key expiration independently of SET operations. Query remaining time-to-live.","**EXISTS(key)** — Check key existence without retrieving value. Useful when only membership matters.","**SCAN** — Iterate over keys matching patterns. Essential for debugging, migration, and administrative operations.","**CAS (Compare-And-Swap)** — Conditional update only if current value matches expected. Enables optimistic locking patterns."],"title":{"icon":"Zap","text":"Extended Cache Operations","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Data Model Requirements**\n\nThe data model defines what types of values the cache can store:\n\n- **Key Constraints**: Keys are typically strings with maximum length limits (e.g., 250 bytes for Memcached, 512 MB for Redis though practical limits are lower). Keys should be lightweight since they're stored in memory.\n\n- **Value Types**: At minimum, support opaque byte arrays. Advanced caches support structured types (strings, integers, lists, sets, sorted sets, hashes, hyperloglog, streams) with type-specific operations.\n\n- **Maximum Value Size**: Define limits for individual values (e.g., 1 MB default for Memcached). Large values impact network transfer time and memory fragmentation.\n\n- **Total Key Space**: The system should support billions of keys across the cluster without degradation.\n\n**TTL and Expiration**\n\nTime-based expiration is fundamental to cache operation:"},"type":"text"},{"data":{"items":["**Per-Key TTL** — Each key can have an independent expiration time, set at write time or modified later.","**TTL Precision** — Second-level precision is typical; millisecond precision may be required for rate limiting use cases.","**Expiration Behavior** — Keys should become inaccessible immediately at expiration. Physical deletion may be lazy (on access) or periodic (background cleanup).","**No-TTL Option** — Some keys should persist indefinitely until explicitly deleted or evicted due to memory pressure."],"title":"Expiration Requirements","variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Write-Through vs Write-Behind","content":"A key functional decision is whether the cache operates independently (cache-aside pattern where clients manage both cache and database) or integrates with the storage layer (write-through where cache writes propagate to database, or write-behind where writes are buffered and batched). Most distributed caches implement cache-aside, leaving synchronization to the application layer.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"non-functional-requirements","title":"Non-Functional Requirements","content":[{"data":{"content":"Non-functional requirements define **how well** the system must perform. For distributed caches, these requirements are often more constraining than functional requirements because caching is fundamentally a performance optimization—a slow cache defeats its own purpose.\n\n**Latency Requirements**\n\nLatency is the defining characteristic of a cache. If the cache is slow, applications will bypass it and hit the origin directly."},"type":"text"},{"data":{"rows":[["p50 (median) GET latency","< 200 μs","Typical case should be imperceptible"],["p99 GET latency","< 1 ms","Tail latency affects user experience"],["p99.9 GET latency","< 5 ms","Extreme tail should remain reasonable"],["SET latency","< 1 ms p99","Writes should not block application flow"],["Network overhead","Minimal","Cache should be co-located with compute"]],"caption":"Latency SLOs for Distributed Cache","headers":["Metric","Target","Rationale"]},"type":"table"},{"data":{"content":"**Throughput Requirements**\n\nA distributed cache must handle massive request volumes. Consider the scale of major deployments:\n\n- **Facebook's Memcached**: Trillions of requests per day, billions of objects cached\n- **Twitter's Cache Layer**: Millions of requests per second for timeline serving\n- **Reddit**: 100,000+ requests per second during peak\n\nOur target system should support:"},"type":"text"},{"data":{"items":["**Per-Node Throughput**: 100,000+ operations per second per cache node","**Cluster Throughput**: Linear scaling—10 nodes should handle 10x the traffic of 1 node","**Burst Handling**: 10x sustained throughput for short bursts (flash sale events, viral content)","**Batched Operations**: MGET/MSET should approach throughput of single operations for moderate batch sizes"],"title":{"icon":"Zap","text":"Throughput Targets","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**Availability Requirements**\n\nCaches sit on the critical path of nearly every request. When the cache is unavailable, applications experience degraded performance (if they can fall back to origin) or complete outages (if the origin cannot handle the load)."},"type":"text"},{"data":{"rows":[["Availability SLA","99.99% (four 9s)","< 53 minutes downtime per year"],["Mean Time To Recovery","< 30 seconds","Automatic failover for node failures"],["Data Durability","Not guaranteed","Cache is ephemeral; loss is acceptable"],["Graceful Degradation","Required","Partial cluster should serve partial traffic"]],"caption":"Availability Targets","headers":["Requirement","Target","Implication"]},"type":"table"},{"data":{"content":"**Scalability Requirements**\n\nThe cache must scale with both data volume and request rate:"},"type":"text"},{"data":{"items":["**Horizontal Scaling**: Add nodes to increase capacity without downtime","**Storage Scaling**: Support petabytes of cached data across the cluster","**Geographic Distribution**: Deploy across multiple regions for global applications","**Elastic Scaling**: Scale up for peak periods, scale down to save costs"],"title":"Scalability Dimensions","variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Thundering Herd Problem","content":"Cache unavailability creates a paradox: when the cache fails, all requests hit the origin simultaneously. If 1,000 concurrent users were being served by cache, suddenly 1,000 requests hit the database—likely crashing it. This 'thundering herd' or 'cache stampede' makes cache availability even more critical than database availability in some architectures.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"scale-estimation","title":"Scale Estimation and Capacity Planning","content":[{"data":{"content":"Before designing the architecture, we must estimate the scale of our distributed cache. These calculations inform decisions about cluster size, memory allocation, network capacity, and cost.\n\n**Reference Architecture Assumptions**\n\nLet's design for a large-scale social media or e-commerce platform:\n\n- **Daily Active Users (DAU)**: 100 million\n- **Average Requests per User per Day**: 100\n- **Cache Hit Rate Target**: 95%\n- **Average Object Size**: 1 KB\n- **Key Size**: 100 bytes average\n- **Unique Objects in Working Set**: 1 billion\n\n**Request Volume Estimation**"},"type":"text"},{"data":{"code":"# Daily request volume\ndaily_requests = 100_000_000 * 100 # 10 billion requests/day\n\n# Requests per second (assuming uniform distribution, which understates peak)\nrps_average = daily_requests / 86400 # ~115,740 RPS\n\n# Peak RPS (typically 3-5x average for social media)\nrps_peak = rps_average * 4 # ~463,000 RPS\n\n# With 95% cache hit rate, origin receives:\norigin_rps = rps_peak * 0.05 # ~23,000 RPS to origin\n\n# Without cache (100% to origin):\n# origin_rps = 463,000 RPS - likely database cannot handle this\n\nprint(f\"Average RPS: {rps_average:,.0f}\")\nprint(f\"Peak RPS: {rps_peak:,.0f}\")\nprint(f\"Origin RPS (with cache): {origin_rps:,.0f}\")\nprint(f\"Cache reduces origin load by: {(1 - 0.05) * 100:.0f}%\")","fileName":"capacity_calculation.py","showLineNumbers":true},"type":"code"},{"data":{"content":"**Memory Requirements**"},"type":"text"},{"data":{"code":"$7c","fileName":"memory_calculation.py","showLineNumbers":true},"type":"code"},{"data":{"content":"**Network Bandwidth Estimation**"},"type":"text"},{"data":{"code":"# At peak: 463,000 RPS\n# Average response size: 1 KB\n# Request overhead: ~200 bytes (headers, key, protocol)\n\nrps_peak = 463_000\nresponse_size = 1024 + 200 # bytes per request/response pair\n\n# Bandwidth per second\nbandwidth_bytes_per_second = rps_peak * response_size\nbandwidth_gbps = (bandwidth_bytes_per_second * 8) / (1024 ** 3)\nprint(f\"Peak bandwidth: {bandwidth_gbps:.2f} Gbps\")\n\n# Per-node bandwidth (assuming 50 nodes)\nnodes = 50\nper_node_gbps = bandwidth_gbps / nodes\nprint(f\"Per-node bandwidth: {per_node_gbps:.2f} Gbps\")\n\n# Each node needs at least 10 Gbps NICs with headroom\n# Consider: client connections, replication traffic, monitoring","fileName":"bandwidth_calculation.py","showLineNumbers":true},"type":"code"},{"data":{"rows":[["Peak Requests Per Second","~460,000 RPS","4x average for social media patterns"],["Total Memory Required","~2 TB","1 billion objects at 1KB + overhead"],["Cache Nodes (256 GB each)","~16 nodes","Before replication"],["Total Nodes with Replication","~32 nodes","2x for single replica"],["Network Bandwidth","~45 Gbps","Aggregate across cluster"],["Per-Node Throughput Target","~15,000 RPS","With headroom for burst"]],"caption":"Capacity Summary","headers":["Resource","Estimate","Notes"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"Interview Tip: Back-of-Envelope Calculations","content":"In system design interviews, you're expected to perform these calculations on a whiteboard. Practice estimation with powers of 2 and 10. Key numbers to memorize: 86,400 seconds/day ≈ 100,000; 1 million seconds ≈ 11 days; 1 KB * 1 million objects = 1 GB. Round aggressively—the goal is order of magnitude, not precision.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"design-constraints","title":"Key Design Constraints","content":[{"data":{"content":"Design constraints are the non-negotiable boundaries within which our cache must operate. These constraints eliminate certain design options and prioritize others.\n\n**Memory as the Primary Resource**\n\nUnlike databases that can spill to disk, caches are fundamentally memory-bound. This constraint shapes nearly every decision:"},"type":"text"},{"data":{"items":["**Fixed Capacity**: Unlike elastic storage, memory has hard limits. The cache must decide what to evict when full.","**Cost**: Memory is expensive (~$5-10 per GB/month for cloud instances). A 2 TB cache at $7.50/GB/month costs $15,000/month just for memory.","**Memory Fragmentation**: Long-running caches experience fragmentation, reducing effective capacity by 10-30%.","**Restart Penalty**: On restart, memory is cold—cache must warm up from origin, creating temporary load spikes."],"title":{"icon":"AlertCircle","text":"Memory Constraints","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**Network as the Bottleneck**\n\nFor in-datacenter caching, the network often becomes the constraint before CPU or memory:"},"type":"text"},{"data":{"items":["**Serialization Overhead**: Every request requires serialization/deserialization. Efficient protocols matter.","**Connection Limits**: Each TCP connection consumes kernel resources. Thousands of clients require connection pooling.","**Bandwidth Limits**: 10 Gbps NICs are common; 25-100 Gbps for high-throughput nodes.","**Latency Sensitivity**: Network jitter directly impacts p99 latency. Co-location with compute is essential."],"title":"Network Constraints","variant":"accent"},"type":"list"},{"data":{"content":"**Consistency vs. Availability Trade-off**\n\nDistributed caches must navigate the CAP theorem:\n\n- **Most caches choose AP (Availability + Partition tolerance)**: When network partitions occur, cache nodes continue serving requests independently, accepting that different clients may see different values.\n\n- **Strong consistency is expensive**: Requiring all replicas to agree before responding adds latency and reduces availability.\n\n- **Eventual consistency is typical**: Applications must tolerate stale reads and handle cache invalidation carefully.\n\n**Multi-Tenancy Considerations**\n\nProduction caches serve multiple applications and teams:"},"type":"text"},{"data":{"items":["**Namespace Isolation**: Different applications' keys should not collide","**Resource Quotas**: Prevent one tenant from consuming all cache capacity","**Traffic Isolation**: One tenant's hot keys should not impact another's latency","**Access Control**: Authentication and authorization for cache access"],"title":"Multi-Tenancy Requirements","variant":"accent"},"type":"list"},{"data":{"icon":"Info","title":"Durability is NOT a Requirement","content":"Unlike databases, caches are explicitly ephemeral. Data loss is expected and acceptable. This assumption enables aggressive performance optimizations—no write-ahead logging, no fsync, no replication quorums. When cache nodes fail, data is regenerated from the origin. If you need durability, you need a database, not a cache.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"common-use-cases","title":"Common Use Cases and Access Patterns","content":[{"data":{"content":"Understanding how applications use caches informs our design priorities. Different use cases exhibit different access patterns, size distributions, and consistency requirements."},"type":"text"},{"data":{"rows":[["Session Storage","Read-heavy, write on login/activity","1-10 KB","30 min - 24 hr","Low tolerance"],["API Response Caching","Read-heavy, write on data change","1-100 KB","Seconds - minutes","Moderate"],["Database Query Cache","Read-heavy, invalidate on write","100 B - 1 MB","Minutes - hours","Critical"],["Rate Limiting","Write-heavy (counters)","8 bytes (counter)","Seconds - minutes","High (approximation OK)"],["Feature Flags","Read-heavy, rare writes","100-500 bytes","Minutes","Moderate"],["User Preferences","Read-heavy, occasional writes","1-5 KB","Hours - days","Low"],["Content/Asset Metadata","Read-heavy, rarely changes","500 B - 5 KB","Hours - days","Low"],["Leaderboards","Read and write heavy","Variable","Real-time","Moderate"]],"caption":"Cache Use Cases and Characteristics","headers":["Use Case","Access Pattern","Object Size","TTL","Consistency"]},"type":"table"},{"data":{"content":"**Hot Key Patterns**\n\nCaches must handle 'hot keys'—individual keys that receive disproportionate traffic:\n\n- **Celebrity Effect**: A viral post or celebrity account can generate millions of requests to a single key\n- **Flash Sales**: A product on sale experiences massive concurrent access\n- **Breaking News**: Trending topics concentrate traffic on few keys\n- **Configuration Keys**: Global settings read by every request\n\nHot keys challenge cache design because:\n1. A single cache node may become overwhelmed\n2. Network bandwidth to that node saturates\n3. Memory for that key's connections exhausts resources\n4. Replication doesn't help if reads all go to primary"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Hot Key Problem","content":"Hot keys can bring down entire cache clusters. Mitigation strategies include: local caching on application servers, key replication across multiple nodes, request coalescing (only one request to origin during refresh), and artificial key distribution (appending random suffixes and aggregating on read).","variant":"warning"},"type":"callout"},{"data":{"content":"**Access Pattern: Zipf Distribution**\n\nReal-world cache access follows a Zipf (power-law) distribution: a small number of keys receive most of the requests. The 80/20 rule often applies—20% of keys serve 80% of requests, and often it's more extreme (1% of keys serving 50%+ of requests).\n\nThis distribution is actually favorable for caching:\n- A relatively small 'hot set' can be kept in the fastest tier\n- Cache effectiveness depends on properly identifying and prioritizing hot data\n- Eviction policies must account for access frequency, not just recency"},"type":"text"}],"titleType":"number","titleNumber":6},{"id":"requirements-summary","title":"Requirements Summary","content":[{"data":{"content":"Let's consolidate our requirements into a comprehensive specification that will guide the design of our distributed cache system."},"type":"text"},{"data":{"left":[{"data":{"items":["**Core Operations**: GET, SET (with optional TTL), DELETE","**Batch Operations**: MGET, MSET for efficiency","**Atomic Operations**: INCREMENT, DECREMENT, CAS","**TTL Management**: Per-key expiration with second precision","**Key Patterns**: Support billions of unique keys","**Value Size**: Up to 1 MB per value (configurable)"],"title":{"icon":"CheckCircle","text":"Functional Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Latency**: < 1ms p99 for all operations","**Throughput**: 100K+ ops/sec per node","**Availability**: 99.99% uptime SLA","**Scalability**: Linear horizontal scaling","**Hit Rate**: Target 95%+ for typical workloads","**Failover**: < 30 second recovery time"],"title":{"icon":"Zap","text":"Non-Functional Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Design Priorities (in order)**\n\n1. **Latency** — Every microsecond matters. Performance is the cache's raison d'être.\n2. **Availability** — The cache must handle failures gracefully; downtime cascades to all dependent systems.\n3. **Throughput** — Support massive request volumes without degradation.\n4. **Scalability** — Grow capacity by adding nodes, not by vertical scaling.\n5. **Simplicity** — Complex systems fail in complex ways. Operational simplicity matters.\n\n**What We Explicitly Do NOT Require**\n\n- **Durability**: Data loss on failure is acceptable\n- **Strong Consistency**: Eventual consistency is sufficient\n- **Complex Queries**: No joins, aggregations, or secondary indexes\n- **Transactions**: No multi-key atomic operations beyond CAS"},"type":"text"},{"data":{"icon":"CheckCircle","title":"Requirements Phase Complete","content":"We have established clear functional and non-functional requirements, performed capacity estimation, identified key constraints, and documented common use cases. This foundation enables us to make principled design decisions. In the next page, we'll explore **Cache Partitioning**—how to distribute data across multiple nodes to achieve the scale and performance we require.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_ad5f04bc7629639ccd1262f901ea33c4","title":"Cache Partitioning","order":1,"content":null,"isLocked":true},{"id":"seed_e6b058ab2d4c36682851a59e4ababace","title":"Consistent Hashing","order":2,"content":null,"isLocked":true},{"id":"seed_e4ed06fcac8a9b98182be9ef254fc17c","title":"Eviction Policies","order":3,"content":null,"isLocked":true},{"id":"seed_25a8ab71dd1c375acda169ed1635f3ab","title":"Cache Coherence","order":4,"content":null,"isLocked":true},{"id":"seed_ce5e70e6e979fbd428604c4ec4e0dc12","title":"Failure Handling","order":5,"content":null,"isLocked":true}]}}