Planned course

System Design Masterclass

Turn requirements into architecture. Practice capacity estimates, failure scenarios and the trade-offs behind distributed systems.

ArchitectureDistributed systemsScalabilityTrade-offs

Join the waitlist ↓

Start date: To be announced
Duration: 3 months · 12 weeks
Format: Live online

300 AZN / month

Monthly tuition

Interest list only for now. Course enrollment is not open yet.

Start date and instructor will be announced before enrollment opens.

Who this is for

Backend developers with API and database experience who want to reason about systems at scale.

CURRICULUM

From requirements to resilient architectures

3 months, 12 weeks, 12 design labs. Expand each week to explore its topics and expected outcome.

12weeks107topics2 + 1projects and capstone

Proposed weekly commitment

Three live sessions of two hours each, plus 5-8 hours of independent study: 11-14 hours per week. The proposed plan includes 72 live teaching hours over 12 weeks; session dates will be announced separately.

Before you start: Recommended for backend developers with 1-3+ years of experience and solid programming, API and database fundamentals. The course is language-agnostic and open to Java, Go, .NET and Node.js developers.

01Month 1 · Weeks 1-4System design foundations

Translate business requirements into architecture with explicit assumptions, workload estimates and trade-offs.

Week 1System design thinking and requirements engineering

Requirements and service objectives

Functional and non-functional requirements, constraints and assumptions
Availability, reliability, scalability, latency, throughput and durability
SLI, SLO, SLA, RTO and RPO

Capacity and bottlenecks

QPS, bandwidth, storage and traffic growth estimates
Back-of-the-envelope calculations and bottleneck identification

Architecture decisions

High-level design (HLD), low-level design (LLD) and ADRs
Design trade-offs, workload assumptions and cost awareness

Design lab: Estimate capacity and design a URL shortener for a hypothetical workload of 100 million redirects per day.
Outcome: Turn an open-ended request into measurable requirements and an initial architecture.

Week 2Networking, load balancing and traffic management

Request path

DNS resolution, TCP, UDP, TLS and HTTP/1.1, HTTP/2, HTTP/3
Reverse proxies, API gateways, ingress and service discovery
CDNs, edge caching and geographic routing

Load distribution

L4 versus L7 load balancing, health checks and connection draining
Round robin, least connections, weighted routing and consistent hashing
Sticky sessions, stateless services and horizontal scaling

Traffic protection

Token bucket, leaky bucket and sliding window rate limiting
Connection pooling, timeouts and overload protection

Design lab: Design a global API platform for traffic spikes and region-based routing.
Outcome: Explain how routing, scaling and traffic limits protect a service during peak demand.

Week 3Database architecture and data modeling at scale

Storage choices

Relational, document, key-value and wide-column databases
OLTP, OLAP, access patterns and schema design
Search engines and specialized indexes

Query correctness and performance

Indexing, B-tree and LSM-tree fundamentals
Query execution, pagination, connection pools and locking
Transactions, ACID, isolation levels and MVCC

Data distribution and recovery

Database replication, read replicas and replication lag
Partitioning, sharding, shard-key selection and rebalancing
Hot partitions, data migration, backup and recovery

Design lab: Design high-volume transaction-history storage with explicit query and retention requirements.
Outcome: Choose a storage and partitioning model from access patterns and correctness requirements.

Week 4Caching, performance and scalability patterns

Cache architecture

CPU, application, database, distributed and edge caching
Cache-aside, read-through, write-through and write-behind
Redis architecture and distributed cache design

Consistency and cache failures

TTL, eviction, invalidation and staleness budgets
Cache stampede, penetration, hot keys and prewarming

Read/write scaling

Write amplification, read/write scaling and materialized views
CQRS and separate read/write models
Latency budgets, p95/p99 measurements and queueing basics

Design lab: Design a high-traffic product catalog with layered caching and a defined staleness budget.
Outcome: Balance cache performance, freshness and recovery behavior in a documented design.

ARCHITECTURE CHALLENGE

URL Shortener and Product Catalog

Design both systems with capacity estimates, component diagrams, API contracts, data models, cache policies and decision records.

02Month 2 · Weeks 5-8Distributed systems and scalability

Reason about partial failures, data correctness, reliable communication and recovery.

Week 5Distributed systems fundamentals and consistency

Failure and consistency models

Distributed computing assumptions and partial failures
CAP theorem, network partitions and consistency trade-offs
Strong, eventual, causal and session consistency
Linearizability versus serializability

Replication and coordination

Leader-follower and quorum-based replication
Read/write quorums and consistency limitations
Logical clocks, ordering, clock skew and coordination

Leadership and correctness

Raft, consensus fundamentals and leader election
Split-brain, fencing tokens and distributed locks
Availability versus correctness under failure

Design lab: Design a replicated account-preferences service and analyze partitions, stale reads and conflicting writes.
Outcome: Explain which consistency guarantees hold during failures and where their limits lie.

Week 6Messaging, events and distributed transactions

Communication and delivery

Synchronous versus asynchronous communication
Queues versus event streams: Kafka, RabbitMQ and managed queues
Partitions, ordering, consumer groups and consumer lag
At-most-once, at-least-once and exactly-once processing scope

Workflow correctness

Idempotent consumers, retry strategies and dead-letter queues
Transactional outbox, CDC and dual-write failures
Saga choreography versus orchestration

Evolution and flow control

Eventual consistency, event schema evolution and replay
Backpressure and bounded message processing

Design lab: Design an order and simulated-payment workflow with retries, deduplication and compensation.
Outcome: Define delivery guarantees and recovery steps across database and messaging boundaries.

Week 7Fault tolerance, availability and disaster recovery

Failure containment

Failure domains, redundancy and single points of failure
Retry storms, timeouts, circuit breakers and bulkheads
Load shedding, backpressure and graceful degradation

Availability architecture

Active-passive versus active-active architectures
Regional failures, failover and traffic shifting
Health checks, graceful shutdown and recovery

Recovery validation

Data durability, backups, restore testing and point-in-time recovery
Disaster recovery planning with RTO and RPO
Chaos engineering and fault-injection methodology

Design lab: Plan and simulate service recovery from database failure, dependency timeouts and a regional outage.
Outcome: Connect recovery objectives to redundancy, failover and tested restoration procedures.

Week 8Observability, performance engineering and reliability

Signals and instrumentation

Metrics, logs and traces
OpenTelemetry, distributed tracing and correlation
RED and USE monitoring methods

Reliability objectives

Latency percentiles, throughput, saturation and error budgets
Golden signals, alerting and dashboard design
SLO-driven architecture and capacity planning

Performance and incidents

Load, stress and soak testing; bottleneck analysis
Little's Law, queues and concurrency limits
Incident response, runbooks and blameless postmortems

Design lab: Diagnose cascading failures from a simulated metrics dashboard and trace waterfall.
Outcome: Use operational signals to identify the bottleneck and propose a measurable reliability improvement.

ARCHITECTURE CHALLENGE

Multi-Channel Notification Platform

Design for millions of daily notifications, traffic bursts, provider failures, priority queues and delivery tracking; justify retries, idempotency and SLOs.

03Month 3 · Weeks 9-12Product architecture and design defense

Design complete systems and defend decisions under business, security, reliability and cost constraints.

Week 9Large-scale product architectures

Interactive products

Social news feeds: fan-out on write versus fan-out on read
Chat and messaging: WebSockets, presence and ordering
Location-aware services: geospatial indexing and proximity queries

Content and search

Media platforms: object storage, CDNs and processing pipelines
File storage: metadata, chunking and upload workflows
Search and autocomplete: inverted indexes and ranking

Isolation and lifecycle

Multi-tenant SaaS: isolation models and noisy-neighbor problems
Data lifecycle, retention and operational cost

Design lab: Choose a chat system, social feed or cloud file store and produce a complete HLD.
Outcome: Adapt shared architecture patterns to the access patterns and lifecycle of a specific product.

Week 10Security, cloud infrastructure and deployment architecture

Identity and threat boundaries

Authentication, authorization and identity boundaries
OAuth 2.0, OIDC, JWT and service-to-service authentication
TLS, mTLS, encryption and secrets management
Threat modeling, least privilege and network segmentation

Protection and governance

OWASP API risks, abuse prevention and rate limiting
Data residency, auditability and compliance requirements

Infrastructure and delivery

Containers, Kubernetes, autoscaling and orchestration fundamentals
Service meshes and ingress architectures
Blue-green, rolling and canary deployment
Infrastructure as Code, cloud cost and managed versus self-hosted services

Design lab: Design a secure multi-tenant SaaS application with deployment, secrets and isolation boundaries.
Outcome: Explain how identity, network, deployment and tenant boundaries address the stated threats.

Week 11System design case studies and interviews

Product case studies

WhatsApp-like messaging
Uber-like dispatch platform
YouTube-like video platform

Correctness-focused case studies

Payment and digital wallet platform
Ticket reservations without overselling

Interview method

Requirements clarification and scope management
Capacity estimation under interview constraints
Architecture walkthrough and bottleneck identification
Defending trade-offs and iteratively scaling a design
Clear communication under technical questioning

Design lab: Complete a timed 45-60-minute architecture exercise and revise the design after feedback.
Outcome: Use a repeatable method to clarify scope, estimate capacity and defend design choices.

Week 12Final capstone and architecture defense

Proposal and models

End-to-end system architecture proposal
Functional and non-functional requirement analysis
Detailed capacity and cost estimates
Data modeling and communication protocols

Correctness and operations

Consistency, scaling and failure-recovery design
Deployment and observability strategy
Security model and threat assessment

Review and defense

Architecture Decision Records (ADRs)
Failure scenarios, bottleneck analysis and improvement plan
Final presentation and instructor-led architecture review

Design lab: Present and defend the payment and wallet architecture using synthetic identities, simulated funds and explicit failure scenarios.
Outcome: Defend the design with requirements, capacity estimates, failure analysis and operational procedures.

ARCHITECTURE CHALLENGE

Global Payment and Digital Wallet System

Design an educational payment platform using synthetic identities and simulated funds, with explicit correctness, recovery and operational requirements.

FINAL CAPSTONE

Global Payment and Digital Wallet System

Design an educational payment platform using synthetic identities and simulated funds, with explicit correctness, recovery and operational requirements.

Model the workload, growth and bottlenecks; compare horizontal scaling options and operating costs.
Use synthetic identities and simulated funds; preserve balance correctness and prevent double spending in the model.
Analyze duplicate requests, concurrent transfers, delayed events, network partitions and simulated provider failures.
Define timeout, crash and duplicate-message recovery across wallet, payment and ledger responsibilities.
Specify authentication, authorization, risk controls and audit boundaries.
Define SLOs, dashboards, alerts, deployment strategy and recovery runbooks.
Deliver architecture diagrams, API contracts, database design, a capacity model, ADRs and failure-mode analysis.
Defend the architecture in a 20-minute presentation covering alternatives, risks and improvements.

Proposed assessment

Weekly design labs: 25%
Month 1 architecture challenge: 15%
Month 2 distributed systems challenge: 20%
Final architecture capstone: 30%
Live design reviews and communication: 10%

Assessment focuses on correctness, scalability, reliability, security, cost and the ability to explain trade-offs. Final assessment rules will be announced before enrollment opens.

Engineering practice

Architecture workshops: design together, challenge assumptions and revise decisions after feedback.
Incident simulations: investigate database saturation, retry storms, stale caches, Kafka lag, regional failures and consistency problems.
Architecture defense and mock interviews: compare alternatives with feedback on correctness, scale, reliability, cost and communication.

By the end of the program

Translate ambiguous business requirements into architectural designs.
Estimate capacity, storage, throughput and operational costs.
Choose databases, caching layers and messaging solutions from requirements.
Reason about replication, sharding, consistency and failure recovery.
Design event-driven workflows and distributed transactions.
Identify security, performance, reliability and scalability risks.
Explain architectural decisions through diagrams, ADRs and presentations.
Approach complex system design interview exercises with a repeatable method.

The course develops practical architecture and decision-making skills. Completing it does not by itself establish senior engineer or software architect proficiency or guarantee employment.

Planned format

Live online sessions and project practice