# System Design

> System design helper for architecting scalable, reliable backend systems. Use when asked to: gather requirements, design an architecture, choose a database, plan for scaling, model events with Kafka, cache with Redis, design an API, deploy on AWS, orchestrate with Kubernetes, or reason about trade-offs. Triggers: "system design", "architecture", "scalability", "scale", "database design", "schema", "Kafka", "event streaming", "Redis", "caching", "API design", "REST", "gRPC", "AWS", "Kubernetes", "k8s", "high availability", "load balancing", "trade-offs", "HLD", "high level design", "design a system like".

- Skill: `amitsharma1994/system-design` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add amitsharma1994/system-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/amitsharma1994/system-design/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: AmitSharma1994 (https://skillmd.com/u/amitsharma1994)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/amitsharma1994/system-design

---


# System Design Skill

A structured playbook for designing scalable, reliable, and maintainable systems.
Work top-down: clarify **requirements** first, then shape the **architecture**, then
drill into each component (**data, scaling, messaging, caching, API, infra**), and
always end by stating the **trade-offs** you accepted.

---

## When to Use

- Designing a new system or service from scratch
- Preparing for a system design interview or review
- Choosing between databases, caches, or messaging systems
- Planning how a system scales from thousands to millions of users
- Deploying and operating services on AWS / Kubernetes
- Documenting the trade-offs behind an architectural decision

---

## The Workflow

Follow these nine stages in order. Each links to a detailed reference.

```mermaid
flowchart LR
    R[1. Requirements] --> A[2. Architecture]
    A --> D[3. Database]
    A --> S[4. Scaling]
    A --> K[5. Kafka]
    A --> C[6. Redis]
    A --> P[7. API]
    A --> I[8. AWS + K8s]
    I --> T[9. Trade-offs]
    D --> T
    S --> T
    K --> T
    C --> T
    P --> T
```

---

### 1. Requirements

Never design before scoping. Separate **functional** (what it does) from
**non-functional** (how well it does it), then derive scale numbers.

- **Functional:** core features, user actions, must-haves vs. nice-to-haves.
- **Non-functional:** availability, latency, consistency, durability, security.
- **Back-of-envelope:** QPS, storage/day, bandwidth, read:write ratio.

See [Requirements Gathering](./references/requirements.md).

---

### 2. Architecture

Sketch the high-level components and how requests flow between them.

- Client → Load Balancer → API/Service layer → Data layer.
- Decide monolith vs. microservices; identify service boundaries.
- Add async paths (queues/streams) where work can be deferred.

See [Architecture Patterns](./references/architecture.md).

---

### 3. Database

Pick storage per access pattern, not by habit. Often **polyglot**.

| Need                          | Pick                          |
|-------------------------------|-------------------------------|
| Strong consistency, relations | SQL (Postgres, MySQL)         |
| High write throughput, scale  | Wide-column (Cassandra)       |
| Flexible documents            | Document (MongoDB, DynamoDB)  |
| Key lookups / cache           | Key-value (Redis, DynamoDB)   |
| Search / full-text            | Search engine (Elasticsearch) |

See [Database Selection & Modeling](./references/database.md).

---

### 4. Scaling

Scale the bottleneck, not everything. Measure first.

- **Vertical** (bigger box) vs. **horizontal** (more boxes).
- Stateless services + load balancing for the app tier.
- **Replication** for read scaling and HA; **sharding/partitioning** for write scaling.
- CDN for static/edge content.

See [Scaling Strategies](./references/scaling.md).

---

### 5. Kafka

Use event streaming to decouple producers from consumers and absorb spikes.

- Topics, partitions (parallelism + ordering), consumer groups.
- Use for: event sourcing, log aggregation, async pipelines, fan-out.
- Delivery semantics: at-least-once by default; idempotent/exactly-once when needed.

See [Kafka & Event Streaming](./references/kafka.md).

---

### 6. Redis

Add caching to cut latency and offload the database.

- Patterns: cache-aside, write-through, write-behind.
- Also: sessions, rate limiting, leaderboards, distributed locks, pub/sub.
- Mind eviction policies, TTLs, and cache invalidation (the hard part).

See [Redis & Caching](./references/redis.md).

---

### 7. API

Design the contract clients depend on. Keep it consistent and versioned.

- REST vs. gRPC vs. GraphQL — match to consumers and latency needs.
- Pagination, idempotency, error model, auth, rate limits, versioning.

See [API Design](./references/api.md).

---

### 8. AWS + Kubernetes

Map the design onto cloud infrastructure and orchestration.

- **AWS:** ELB/ALB, EC2/EKS/Lambda, RDS/DynamoDB, S3, SQS/MSK, CloudFront.
- **Kubernetes:** Deployments, Services, Ingress, HPA, ConfigMaps/Secrets, probes.

See [AWS Deployment](./references/aws.md) and [Kubernetes](./references/kubernetes.md).

---

### 9. Trade-offs

Every choice costs something. State it explicitly.

- CAP: consistency vs. availability under partition.
- Latency vs. consistency, cost vs. performance, simplicity vs. flexibility.
- Document *why* you chose A over B.

See [Trade-offs & Decision Records](./references/trade-offs.md).

---

## Quick Checklist

- [ ] Functional + non-functional requirements written down
- [ ] Scale estimated (QPS, storage, read:write ratio)
- [ ] High-level diagram with clear component boundaries
- [ ] Database chosen per access pattern (+ schema sketch)
- [ ] Scaling plan: replication / sharding / caching / LB
- [ ] Async paths identified (Kafka/queues) where useful
- [ ] Caching strategy + invalidation defined (Redis)
- [ ] API contract: versioning, errors, auth, pagination
- [ ] Deployment target mapped (AWS services + K8s objects)
- [ ] Trade-offs and bottlenecks explicitly stated

---

## Reference Files

- [Requirements Gathering](./references/requirements.md)
- [Architecture Patterns](./references/architecture.md)
- [Database Selection & Modeling](./references/database.md)
- [Scaling Strategies](./references/scaling.md)
- [Kafka & Event Streaming](./references/kafka.md)
- [Redis & Caching](./references/redis.md)
- [API Design](./references/api.md)
- [AWS Deployment](./references/aws.md)
- [Kubernetes](./references/kubernetes.md)
- [Trade-offs & Decision Records](./references/trade-offs.md)