DevOps Engineering Case Studies

System Design

Distributed systems designed end to end — requirements, capacity estimation, API and data model, architecture, deep dive on the bottleneck, and the trade-offs that only show up on the second pass.

This section predates the repository's shift toward DevOps and SRE case studies, and it is kept because the two disciplines meet constantly in practice. The design decisions here are the ones that determine how a system behaves when it is operated: whether a redirect can be revoked, whether a fan-out is push or pull, whether a rate limiter degrades open or closed. Those choices become somebody's incident later.

Case studies

# System Difficulty
001 URL Shortener Easy
002 Rate Limiter Medium
003 Pastebin Easy
004 Chat System Hard
005 Notification Service Medium

Also here: Twitter system design, a standalone interactive page.

Mock interviews

Method

The same seven steps every time, because the structure is the part that transfers to a real round:

  1. Clarify requirements — functional, non-functional, and explicitly out of scope
  2. Estimate scale — traffic, storage, bandwidth
  3. Define the API and data model
  4. Draw the high-level architecture
  5. Deep dive on the bottleneck
  6. Talk through the trade-offs, including the option rejected and why
  7. Note what you would improve with more time
001easy

URL Shortener

Designing a read-heavy URL shortener end to end — Base62 key space sizing, distributed ID generation, the 301-vs-302 decision that cannot be undone, four-tier caching, hot-link handling, and abuse control.

002medium

Rate Limiter

Designing a distributed rate limiter end to end — the five algorithms and when each is right, atomic token buckets in Redis, the two-tier local/central hybrid, hot-key sharding, per-route fail-open policy, and multi-region limit slicing.

003medium

Pastebin

Designing a text-sharing service end to end — key generation, blob vs metadata storage, expiry and burn-after-read semantics, CDN-backed read path, and the optimizations that keep a read-heavy system cheap.

004hard

Chat System

Designing a real-time messaging system end to end — persistent connections and session routing, per-conversation ordering, at-least-once delivery with client dedupe, offline push, multi-device sync, presence, and where end-to-end encryption changes the architecture.

005medium

Notification Service

Designing a multi-channel notification system end to end — accept-then-deliver queues, the eligibility pipeline that decides whether to send at all, template rendering, provider quotas and failover, retries without duplicates, bounce and suppression handling, and digesting.

Interviewer Checklist

Scoring a system design round consistently — requirements, estimation, architecture, trade-offs, communication.

Mock Interview: URL Shortener

A timed prompt for designing a URL shortener, with the clarifications a strong candidate asks for.

Mock Interview: Notification Service

A timed prompt for designing a multi-channel notification service.

Mock Interview: Chat System

A timed prompt for designing a real-time chat system.

Mock Interview: News Feed

A timed prompt for designing a news feed, including the push-vs-pull fan-out decision.

Mock Interview Session Template

A structure for recording one mock system design round: what was asked, what was covered, and where the time went.

Twitter System Design