Sefism System Design Roadmap

What this roadmap is

The System design roadmap is a seven-stage learning path for engineers who can build a service and want to reason about how systems behave at scale, under failure and across teams. It moves from the vocabulary of scale and the components in front of every system, through data storage, networking and distributed systems, to resilience patterns, observability, and finally complete designs worked from a blank page.

There is no edition to choose: everyone follows the same stages. The roadmap treats every concept as a trade-off with a cost on both sides, and asks you to produce designs rather than only read them.

What you can do at the end

The roadmap sets five outcomes:

• Estimate traffic and storage for a product and turn the numbers into decisions about caching, databases and partitioning.
• Choose a database, replication setup, shard key and cache for a workload, and say what goes stale and why that is acceptable.
• Explain what a distributed system does under partitions, slow replicas and retries, using quorums, consensus and idempotency.
• Specify timeouts, retries, circuit breakers, SLOs and tracing for a service so it degrades gracefully and failures are visible.
• Design a feed, chat app or ride-hailing service end to end in 45 minutes: requirements, estimates, diagram, bottlenecks and trade-offs.

In short, you can take a vague product requirement to a defensible architecture and explain every trade-off in it.

Who it suits, and who should start elsewhere

It suits backend and full stack engineers, final year students who have built at least one service with a database, and mid-level engineers who are starting to own larger pieces of a system.

It assumes you can already build and deploy an API. If not, follow the Backend development roadmap first; system design concepts stick far better once you have run a service yourself. If you are earlier still, the SQL and databases roadmap builds the data foundation that stage 2 relies on. If your interest is the code inside one service (classes, patterns, clean code) rather than how services fit together, the Software design and clean code roadmap is the right path.

Time and pace

The seven stages total about 285 hours. The first stage is a foundation: if you already know the core vocabulary, your plan lets you skim or skip it.

A student's week (10 to 12 hours): two sessions reading and watching the stage's material, one session keeping your own one-page map of problems to tools (the roadmap's advice for stage 1), and one session drawing a design or writing the stage's milestone. In stage 7, that becomes two timed designs a week.

Someone working full time (about 5 hours): one evening of reading and one weekend design session. Use your day job: for each stage, write down how your own system handles the topic (its timeouts, its indexes, its release process). It is the fastest way to make the concepts concrete.

Stage by stage

1. Core concepts and building blocks (about 35 hours, foundation)

Vertical versus horizontal scaling and stateless services, latency, throughput and percentiles, availability, redundancy and SLOs, back-of-the-envelope capacity estimates, load balancers and balancing algorithms, reverse proxies and API gateways, CDNs and edge caching, caching patterns, eviction and invalidation, CAP and PACELC, and optionally Bloom filters.

Milestone: estimate requests per second, storage and bandwidth for a photo-sharing app with 10 million daily users, draw the request path through DNS, CDN, load balancer, cache and database, and write what users see when each one fails.

2. Data storage, partitioning and replication (about 40 hours)

The stage the roadmap asks you to give the most care, because most scaling problems end up here. SQL versus NoSQL and the NoSQL families, data modelling from access patterns, indexes and query plans, ACID transactions and the write-ahead log, isolation levels and concurrency anomalies, replication and read replicas, partitioning and sharding, choosing shard keys, hot spots and resharding, denormalisation for reads, and object storage for large files.

Milestone: a one-page data plan for a read-heavy app with 10 million users: schema and indexes for its two main entities, a replication setup, a shard key and its hot-spot risk, what you denormalise, and where media is stored.

3. Networking, APIs and messaging (about 30 hours)

DNS and the request path, TCP and UDP, HTTP/1.1, HTTP/2, HTTP/3 and TLS, REST API design, gRPC and GraphQL, WebSockets, SSE and long polling, synchronous versus asynchronous communication, message and work queues, and pub/sub and event streams.

Milestone: design the API and message flow for placing an order in a food delivery app: the endpoints, which calls are synchronous, what goes on a queue, how the rider app gets live location updates, and why.

4. Distributed systems fundamentals (about 45 hours)

Partial failure, unreliable networks and clocks, consistency models from strong to eventual, heartbeats, failure detection and gossip, quorum reads and writes, leader election and consensus with Raft, consistent hashing, idempotency and at-least-once delivery, and optionally Merkle trees and the transactional outbox.

Milestone: implement consistent hashing with virtual nodes in your language, add and remove a node and measure how many keys move; then describe how a store with N=3, W=2, R=2 behaves when one replica is down, and when two are.

5. Architecture and resilience patterns (about 40 hours)

Monolith versus microservices, API gateway and backend for frontend, service discovery and sidecars, timeouts, retries, backoff and jitter, circuit breakers and bulkheads, dead letter queues and backpressure, rate limiting, load shedding and graceful degradation, sagas across services, and optionally event sourcing and CQRS.

Milestone: for a checkout call chain, write each hop's timeout, retry policy, circuit breaker threshold and fallback, then design the saga that refunds the payment when stock reservation fails, including where failed messages go.

6. Performance, observability and safe releases (about 35 hours)

Metrics and the golden signals, p99 latency and the hot path, structured logs and correlation IDs, distributed tracing, health checks, SLOs, error budgets and alerting, blue-green and canary releases, feature flags, and optionally chaos engineering. A checklist of practical performance moves comes with it, from checking query plans on the hot path to pooling connections and moving heavy work onto a queue.

Milestone: add structured logs, a health check and a p99 latency metric to a service you built, load test it, find the slowest step in a trace, cut its p99, and record the before and after numbers.

7. Designing real systems end to end (about 60 hours)

One repeatable framework applied to complete problems: requirements and scope, capacity estimates that drive decisions, API and data model, the high-level diagram, recurring building blocks such as IDs, search and storage, deep dives and bottlenecks, failure handling and trade-offs, practising full designs against the clock, and learning from engineering blogs and papers. The stage's checklist lays out three weeks of practice designs, including a news feed, YouTube, Dropbox, typeahead search, a rate limiter, a messenger, a web crawler, proximity search, Uber and Ticketmaster.

Milestone: design at least ten systems from a blank page, 45 minutes each, compare each with a published solution and write down the three biggest gaps.

Projects that prove it

The roadmap links six build projects, so the concepts leave the whiteboard:

• Low-latency read API: a measured performance case study
• Distributed tracing for a polyglot microservice system
• Chaos engineering toolkit for teaching distributed systems
• Collaborative whiteboard with conflict-free sync
• Distributed key-value store with Raft consensus
• Crowdsourced public transport arrival tracker

How it works on Sefism

The public page at /roadmaps/system-design/ shows the full stage list, with the first two stages open to read. Everything on Sefism is free to learn from; a few actions, such as adding a roadmap to your dashboard, use credits. New members get starting credits, the first roadmap is free, and you can ask for more if you run out while learning seriously.

Adding the roadmap opens every stage in your dashboard, where you set your weekly hours and familiarity and track progress topic by topic. Each topic has an explanation, a check question, and a prompt that makes an AI assistant quiz you rather than give answers. Following the roadmap also unlocks the companion cheat sheet. If a stage leaves you with a question, you can send it to Tauseef.

The companion cheat sheet

The System design cheat sheet condenses the building blocks and trade-offs into ten chapters with a 144-term glossary. Read a chapter before a design discussion, or use the glossary to refresh a term you half remember.

Related on Sefism

• How do I learn system design as a student or junior developer?
• How do I learn system design for AI applications?
• Designing Data-Intensive Applications, the reference for stages 2 and 4.
• Distributed Systems lecture series by Martin Kleppmann, which the roadmap suggests watching before any pattern catalogue.
• The System Design Primer and the Google SRE book.

What you can do afterwards

You will have a set of written designs with your own gap notes, a measured performance improvement on a real service, and working code for at least one distributed systems idea. That is the evidence that you can own larger parts of a system, discuss architecture with senior engineers, and grow towards senior roles; the Mid-level to senior roadmap picks up from there.

Frequently asked questions

How long does it take to learn system design? This roadmap is about 285 hours: roughly 24 weeks at 12 hours a week, or just over a year at 5. It keeps going after that: the roadmap asks you to read engineering blogs and compare your designs with how real companies built theirs.

Can a junior developer or student learn system design? Yes, once you have built and deployed at least one service. Start with stages 1 and 2 and connect each concept to something you have built.

Do I need to know distributed systems theory? Stage 4 covers what you need: partial failure, consistency models, quorums, Raft, consistent hashing and idempotency. The roadmap's advice is to understand why clocks and networks cannot be trusted before memorising patterns.

Should I start with microservices? No. The roadmap advises starting from a well-structured monolith and making the design earn every service boundary.