System Design
A method for designing systems, from requirements to written trade-off analysis.
This program is planned and not scheduled yet. No date, price or cohort has been announced. If you register interest, we contact you when it is scheduled or to discuss an individual format.
Objective
The program treats system design as a repeatable method: pin down requirements and quality attributes, estimate scale, shape the API and data model, and justify choices through trade-offs. The method is applied to 6–8 classic case studies, each ending with a written trade-off analysis.
Who it's for
- Senior candidates who want to learn to think about backend systems as a whole
- People moving towards a tech lead or architecture role
- Engineers who want to argue their position in design discussions in a structured way
- Those who want to pull their knowledge of microservices, databases and messaging into one framework
Who it's not for
- Anyone without backend experience: the Java Backend Career Track is recommended first
- Anyone looking for memorised answer templates for interviews: the program focuses on reasoning, not memorisation
- Anyone who wants to learn the configuration of a specific technology
Prerequisites
- Experience writing real backend services
- SQL, index and transaction fundamentals
- HTTP and REST API design
- Knowing what a cache and a message queue are
What you will be able to do
What you will be able to do
- Turn an ambiguous task into functional and quality requirements
- Run simple estimates for traffic, storage and bandwidth
- Design an API and data model that fit the access patterns
- Assess a caching strategy (aside, write-through) and its invalidation risk
- Justify when a queue and asynchronous processing are needed
- Compare storage choices (relational, key-value, search, object) for a workload
- Analyse options for scaling reads and writes (replicas, sharding, partitioning)
- List failure modes and propose a response for each
No education program can guarantee employment or a promotion.
Curriculum
Curriculum
- 01
Requirements and quality attributes
Before designing, we pin down what we are solving and what we are not.
- Functional and non-functional requirements
- Availability, latency, durability and consistency attributes
- Writing constraints and assumptions down explicitly
- The notion of SLIs and SLOs
- Limiting scope
Hands-on lab: For an ambiguous task, write a list of requirements and assumptions and define the non-goals.
- 02
Estimation
What matters is not an exact number but an order of magnitude that affects a decision.
- Requests per second and the peak factor
- Storage and bandwidth arithmetic
- Read/write ratio
- How an estimate changes a decision
- Stating assumptions openly
Hands-on lab: Prepare a traffic and storage estimate for a chosen system and write down which decision the result affects.
- 03
API and data design
Starting from access patterns and shaping the API and data model around them.
- Resource and operation design
- Pagination, idempotency and rate limits
- Normalisation and denormalisation
- Matching indexes to access patterns
- Schema evolution
Hands-on lab: Produce an API contract and table schema for a given system and explain how the key queries execute.
- 04
Caching and queues
Weighing the value and the risk of two main tools for reducing latency and smoothing load.
- Cache-aside, write-through, write-behind
- Invalidation and stale data
- Cache stampede and protection
- Decoupling load with queues, and backpressure
- Dead letters and retries
Hands-on lab: Add a cache to a read-heavy service and simulate stale-data and stampede scenarios.
- 05
Storage choice and scaling
Choosing storage that fits the workload and comparing options for scaling reads and writes.
- Relational, key-value, document, search and object storage
- Read replicas and replication lag
- Shard keys and the difficulty of re-sharding
- The hot key problem
- The practical meaning of CAP and PACELC
Hands-on lab: Write a short decision document comparing two storage options for the same workload.
- 06
Consistency and failure modes
Thinking in advance about where and how the system will break.
- Strong, eventual and causal consistency
- Hunting single points of failure
- Timeouts, retries and idempotency
- Partial failure and degradation strategy
- Disaster recovery concepts: RPO and RTO
Hands-on lab: Prepare a failure-mode table for a designed system with a response and an impact estimate for each mode.
- 07
Case studies I: URL shortener, rate limiter, notifications
Applying the method to three classic problems with a relatively narrow scope.
- URL shortener: ID generation, redirect load, analytics
- Rate limiter: token bucket, sliding window, distributed counters
- Notification system: channels, priorities, retries
- Estimation and trade-off analysis for each
Hands-on lab: Pick two of the three problems and produce a full written design document with a trade-off analysis.
- 08
Case studies II: payments ledger, feed, search
Analysing three problems that are harder in terms of consistency, scale and retrieval.
- Payments ledger: double-entry, idempotency, audit trail
- Feed: fan-out on write versus read, hot users
- Search: inverted index, indexing delay, relevance
- Consistency and failure analysis for each
Hands-on lab: Pick one of the three problems, write a design document and rework it after peer review.
Practice assignments
- A requirements and assumptions document
- A traffic and storage estimate
- An API and data model design
- A decision document on storage choice
- A case-study design document and a peer review
Portfolio deliverables
- Written design documents for 6–8 case studies
- A trade-off analysis and alternatives in each design
- A failure-mode table
- A short ADR for a chosen design
How learning is assessed
- Design defense (before a mentor and peers)
- A written case-study analysis
- A peer design review
- Mentor feedback on the quality of trade-off reasoning
Tools and technologies
- PostgreSQL
- Redis
- Kafka or RabbitMQ
- Elasticsearch or OpenSearch (conceptual)
- The C4 model
- Diagramming tools
- ADR templates
- k6 or JMeter (simple load tests)
Level progression
- Before
- Before: Microservices and Distributed Systems, Kafka and Event-Driven Architecture, or equivalent experience.
- After
- After: programs in the tech lead or solution architect direction.
- Length and format
- Length and format are not set yet; the program is planned and not scheduled.
Frequently asked questions
Frequently asked questions
Is this program available now?
No. It is planned and not scheduled yet. No dates or prices have been announced. You can register interest or request a consultation.
Is this interview preparation?
Its main aim is real design thinking. The method can help in interviews too, but there are no memorised templates and no outcome promised.
Will we write code or only draw diagrams?
The main output is written design documents. Some labs involve small experiments on caching, load and query plans.
Is there a certificate or a job promise?
No. No certificate or outcome is promised. Evaluation takes the form of design defenses and mentor feedback and is a recommendation only.
Articles related to this program
- System designCaching strategies - cache-aside, write-through, TTLs and stampedes
- Cloud architectureCloud architecture basics for backend engineers
- Distributed systemsFailure handling in distributed systems
- Distributed systemsIdempotency patterns for safe retries
- SQL and performanceSQL indexes explained with PostgreSQL EXPLAIN
- System designA repeatable method for system design interviews and design reviews