Cheat Sheet — System Design

Stale data, thundering herd, cache stampede. 5. Asynchronous Processing Patterns | Pattern | Description | Use case | |---------|-------------|----------| | Message queue | Producer → queue → consumer | Task distribution, load smoothing | | Pub/Sub | One-to-many fanout | Event-driven updates, notifications | | Event sourcing | Store state as event log | Audit, replay, CQRS | | CQRS | Separate read/write models | Complex domains, high read/write asymmetry | | Saga | Distributed transaction via compensating events | Cross-service consistency |

Ordering, at-least-once vs exactly-once, dead-letter queues, backpressure. 6. Consistency & Replication | Model | Behavior | Latency | Data loss risk | |-------|----------|---------|----------------| | Strong | All reads see latest write | Higher | None (if quorum) | | Eventual | Reads may be stale, converge over time | Lower | Possible during failover | | Read-your-writes | Session sees own writes | Medium | None | | Monotonic reads | Reads never go back in time | Medium | None | system design cheat sheet

Start with relational. Scale with read replicas → cache → sharding → NoSQL when needed. 4. Caching Strategies | Strategy | How it works | Best for | |----------|-------------|-----------| | Cache-aside | App checks cache → misses DB → writes cache | Read-heavy workloads | | Read-through | Cache sits in front of DB | Consistent data, complex queries | | Write-through | Write to cache + DB synchronously | Write-heavy, need consistency | | Write-behind | Write to cache → async write to DB | High write throughput, eventual consistency | | Refresh-ahead | Cache auto-refreshes near-expiry data | Predictable access patterns | Stale data, thundering herd, cache stampede

LRU, LFU, TTL, FIFO.

Pick 2 of (C, A, P) — in practice, AP (eventual consistency) or CP (strong consistency with possible downtime). 3. Database Selection Guide | Workload | Recommendation | Rationale | |----------|---------------|-----------| | Strong ACID, complex joins | PostgreSQL, MySQL (RDBMS) | Transactions, referential integrity | | High write throughput, simple lookups | Cassandra, DynamoDB | Partitioned wide-column | | Flexible schema, rapid iteration | MongoDB, Couchbase | Document store | | Search | Elasticsearch | Inverted indexes, full-text | | Real-time analytics | ClickHouse, Druid | Columnar storage | | Graph relationships | Neo4j, ArangoDB | Graph traversal | complex joins | PostgreSQL

1. Core Building Blocks | Component | Purpose | Common Tech | |-----------|---------|--------------| | Load Balancer | Distribute traffic | Nginx, HAProxy, AWS ELB | | API Gateway | Auth, rate limiting, routing | Kong, Apigee, AWS API Gateway | | Database | Persistent storage | PostgreSQL, MySQL, Cassandra, DynamoDB | | Cache | Reduce latency, offload DB | Redis, Memcached, CDN | | Message Queue | Async decoupling | Kafka, RabbitMQ, SQS | | File Storage | Blob/object storage | S3, GCS, Azure Blob | | CDN | Serve static assets | Cloudflare, CloudFront, Akamai | 2. Key Characteristics & Trade-offs | Characteristic | What it means | How to achieve | |----------------|---------------|----------------| | Availability | System stays up | Redundancy, failover, replication | | Consistency | All nodes see same data | Quorums, transactions, locks | | Partition Tolerance | Works despite network splits | Distributed architecture (CAP theorem) | | Scalability | Handle more load | Horizontal scaling, sharding, caching | | Latency | Response time | Caching, CDN, efficient indexes | | Throughput | Requests/second | Parallelism, async processing, batching | | Durability | Data persists after failure | Replication, WAL, backups |

TOP

zalo