Backend System Design Roadmap: LLD, Databases and Real Systems
The backend (SDE) system design roadmap after the core: low-level design, API and database depth, reliable async work and the building blocks of classic questions.
This backend system design roadmap is for backend and full-stack engineers (the SDE roles most companies hire for). Backend interviews run two kinds of design round: high-level design (HLD), where you architect a whole system, and low-level design (LLD), where you design the classes inside one component. The core system design roadmap already covers most of the HLD round. This one picks up where it ends: low-level design, the depth interviewers probe in APIs and databases, async work that's safe to retry, and the mechanisms behind the classic questions.
New to system design? Do the core roadmap first. Already comfortable with load balancers, caches, queues and sharding? Start here.
Builds on the core system design roadmap. Do that first, or skip the parts you already know; this one only covers what backend and full-stack interviews go deeper on.
Step 1Low-level design
The LLD or machine-coding round: clean classes inside one service.
Step 2APIs in depth
Contracts that clients can page through, retry and build on.
- REST vs gRPC vs GraphQLIntermediate
- PaginationBeginner
- WebhooksBeginner
- Design a webhook serviceGood to know
- WebSockets, SSE, pollingGood to know
Practice:URL shortenerBackend · Beginner · FreeWebhook receiver serviceBackend · Intermediate
Step 3Databases in depth
Keeping data correct when many requests touch it at once.
Step 4Reliable async work
Making events and multi-step workflows safe to retry.
- Database per serviceIntermediate
- Outbox and CDCAdvanced
- SagasAdvanced
- Event sourcing and CQRSGood to know
Practice:Notification delivery serviceBackend · Intermediate · Free
Step 5Real-world building blocks
The mechanisms behind the classic questions.
- RedisBeginner
- Pre-computingIntermediate
- Two-stage processingIntermediate
- Design typeaheadIntermediate
- Resumable uploadsIntermediate
- Job schedulingAdvanced
- Payments and ledgersAdvanced
- Geospatial indexingGood to know
- Design TinderGood to know
Practice:Search autocomplete serviceBackend · IntermediateCloud file storageBackend · AdvancedDistributed task schedulerBackend · Advanced · FreePayment processing platformBackend · AdvancedSwipe-based dating appBackend · Advanced
What backend interviews actually test
| Round | What you produce | Where it's covered |
|---|---|---|
| High-level design | Requirements, estimates, an architecture diagram, data model and the trade-offs behind each component | The core roadmap, then steps 2 to 5 here for the deep dives |
| Low-level design | Classes, interfaces and relationships for one component, plus how they handle change and concurrency | Step 1: SOLID and design patterns |
| Deep dives inside HLD | One part of the design in detail: the API contract, the schema and its locks, the queue consumer, the failure path | Steps 2 to 4 |
Junior roles lean on a clean architecture and correct storage choices. Mid-level roles add concurrency and consistency trade-offs. Senior roles are judged on the deep dives: what breaks first, how you'd know, and what you'd change at ten times the load.
The questions this roadmap prepares you for
| Question | Topics it leans on |
|---|---|
| Design a URL shortener | API design, idempotent writes, unique IDs, caching |
| Design a ticketing platform | Optimistic vs pessimistic locking, transactions, queues for traffic spikes |
| Design search autocomplete | Tries, precomputed top-k, caching at the edge |
| Design cloud file storage | Chunked and resumable uploads, object storage, metadata databases |
| Design a distributed task scheduler | Delayed jobs, leases, at-least-once execution |
| Design a payment platform | Idempotency, double-entry ledgers, sagas, reconciliation |
| Design a notification service | The outbox pattern, retries, delivery guarantees |
A three-week plan
This assumes you've finished the core roadmap, or know its topics well enough to explain them without notes.
- Week 1: steps 1 and 2. Write one LLD (a parking lot or a rate limiter class design) using the patterns in step 1, then design the API for the URL shortener with pagination, idempotency keys and error responses.
- Week 2: steps 3 and 4. For every design you practise, write the main table schema, name the index each query uses, and say what happens when two requests change the same row. Make one flow asynchronous with an outbox and walk through a consumer crashing mid-message.
- Week 3: step 5. Three full timed designs from the table above, each followed by a written list of what you'd improve.
Frequently asked questions
How is this different from the core system design roadmap?
The core roadmap teaches the building blocks every design round uses, whatever your role: networking, storage, caching, queues, distributed systems basics and reliability. This roadmap only covers what backend interviews go deeper on, so no topic appears in both. Do the core first unless you already know it.
Is low-level design asked in every company?
No. Many product companies in India and some global ones run an LLD or machine-coding round, especially for SDE-1 and SDE-2. Others fold class design into a coding round or skip it. Check the interview loop with your recruiter, and prepare step 1 if it's listed.
Which language should I use for LLD?
Any object-oriented language you write fluently: Java, C++, Python, C# or TypeScript. Interviewers judge the structure (responsibilities, interfaces, extensibility), not the syntax.
How many design questions should I practise?
Ten to fifteen distinct questions, done properly with a review afterwards, is more useful than skimming fifty solutions. The interview questions list groups them by level.
Further reading
- Designing Data-Intensive ApplicationsMartin Kleppmann, O'Reilly
- Refactoring Guru: Design PatternsRefactoring Guru
- Microsoft REST API GuidelinesMicrosoft, GitHub