Scribd
Upload
5 views2 pages

Distributed Cache

The document outlines a design for a distributed caching layer intended for high-throughput applications, estimating 1 million daily active users and peak requests of 1,000 per second. It details the architecture, core components, API design, non-functional requirements, key trade-offs, failure scenarios, and scaling strategies. The system emphasizes durability, scalability, and performance while addressing potential challenges such as node failures and data corruption.

Uploaded by

gregory.borodin
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views2 pages

Distributed Cache

The document outlines a design for a distributed caching layer intended for high-throughput applications, estimating 1 million daily active users and peak requests of 1,000 per second. It details the architecture, core components, API design, non-functional requirements, key trade-offs, failure scenarios, and scaling strategies. The system emphasizes durability, scalability, and performance while addressing potential challenges such as node failures and data corruption.

Uploaded by

gregory.borodin
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

System Design: Distributed Cache

Problem Statement
Design a distributed caching layer similar to Memcached or Redis for high-throughput apps.

Scale Estimates
Metric Estimate

Daily Active Users 1M

Peak Requests/sec 1K

Total Storage 1TB

High-Level Architecture

Client --> CDN --> Load Balancer --> API Gateway --> Service Layer --> Data Layer
| |
Rate Limiter Cache Layer

Core Components
Message Queue (RabbitMQ)
TimescaleDB
MinIO
CDN (CloudFront)
API Gateway (Kong)

Data Model
Key entities and their relationships:

Entity Storage Access Pattern

distributed_cache_record Primary DB Read-heavy, indexed by ID

distributed_cache_metadata Cache + DB Write-through caching

distributed_cache_event Event Store Append-only, time-partitioned

distributed_cache_audit Cold Storage Write-once, query by date range

API Design

POST /api/v1/distributed-cache - Create resource


GET /api/v1/distributed-cache/{id} - Get by ID
PUT /api/v1/distributed-cache/{id} - Update resource
GET /api/v1/distributed-cache?page=1 - List with pagination
DELETE /api/v1/distributed-cache/{id} - Soft delete
GET /api/v1/distributed-cache/health - Health check endpoint

Non-Functional Requirements
Storage: Up to 100TB per tenant
Observability: Distributed tracing, < 1% overhead
Durability: Zero data loss, 3x replication
Consistency: Eventually consistent, < 5s propagation
Scalability: Horizontal to 1000+ nodes

Key Trade-offs
Storage vs Compute: Pre-computed aggregations reduce query time but increase storage 3x
Consistency vs Latency: Relaxed to eventual consistency for sub-100ms response times
Sync vs Async: Async for throughput at cost of immediate feedback
SQL vs NoSQL: NoSQL for flexible schema at cost of ACID transaction support

Failure Scenarios & Mitigations


1. Node Failure: Automatic failover with health checks every 10s
2. Network Partition: Graceful degradation returning cached/stale data
3. Data Corruption: Checksums on write, periodic integrity audits
4. Cascading Failure: Circuit breakers with exponential backoff
5. Hot Partition: Consistent hashing with virtual nodes for even distribution

Scaling Strategy
Read scaling: Add read replicas and cache layers
Write scaling: Partition/shard by tenant or entity ID
Compute scaling: Auto-scale worker pools based on queue depth
Storage scaling: Tiered storage (hot/warm/cold) with lifecycle policies

System Design Document | Generated for study and reference purposes

You might also like