Defend Your Backend Design Choices
Build the systems senior interviews actually ask about. Walk in with the reps to defend every choice.
What You Will Learn
- ✓Design under hard constraints, not vibes
- ✓Choose between pessimistic and optimistic concurrency for the right reasons
- ✓Build idempotent APIs that survive duplicate requests
- ✓Reconstruct state from an event log
- ✓Reason about cache stampedes, dead-letter queues, and connection pools
- ✓Defend tradeoffs in system design interviews from real reps
- ✓Ship a microservices stack with a real API gateway
- ✓Walk into a senior interview with a portfolio you can actually demo
Who Is This For
- Mid-level backend engineers who who want to push toward senior but only ever ship CRUD at work
- Engineers prepping for system design interviews who who can recite patterns but have never actually built any of them
- Indie hackers who whose side projects just hit real users and are starting to break
- Self-taught seniors who who want production reps without the politics of changing jobs
Curriculum
Data infrastructure
4 lessons
High scale
4 lessons
Distributed systems
4 lessons
Production lifecycle
4 lessons
Production operations
4 lessons
Frequently Asked Questions
- How is this different from the Backend Masterclass?
- The Masterclass teaches the language. The Accelerator makes you fluent under pressure. Masterclass walks you from zero to production patterns. Accelerator drops you into real briefs and forces you to defend a design choice for each one.
- Do I need backend experience already?
- Yes. You should be comfortable building REST APIs and querying a database. If you cannot ship a CRUD service yet, start with the Backend Masterclass first.
- Why two solutions per project?
- Because real engineering is about tradeoffs. Pessimistic vs optimistic locking. Simple cache vs cache with stampede protection. Knowing both options and when each one is right is how you stop sounding like a junior in design reviews.
- Will these projects look good in interviews?
- Yes. Each one is a runnable repo with a written tradeoff analysis. You can ship them to GitHub, link them on your resume, and walk through the design out loud. That is the conversation that promotes engineers.
Defend Your Backend Design Choices
Build the systems senior interviews actually ask about. Walk in with the reps to defend every choice.
Built for engineers who want production reps without changing jobs
You can ship features. So why does this still happen?
CRUD ceiling
Your tickets are all "add a field" or "fix a bug." You never get to design anything that has to survive concurrency, scale, or failure.
System design panic
The interviewer asks how you would build a ticketing system. You know the words. You have never actually built one.
Pattern flashcards
You can name idempotency, event sourcing, and pessimistic locking. You cannot pick which one fits this problem and defend it.
Side project breaking under real load
You shipped your indie product. Real users showed up. Now race conditions, duplicate webhooks, and stale caches are eating your week.
The fix is not more system design videos.
It is real reps with hard constraints.
Senior engineers aren't better because they know more syntax. They're better because they've:
Real briefs. Two solutions each. Real repos. By the end, system design feels like something you have done, not something you have read about.
Not another system design video.
Real backend systems with real tradeoffs.
Every project comes with a brief, hard constraints, two complete solution approaches, and a written tradeoff. You clone the repo, run it under load, see how it breaks, and learn why one approach beats the other for this problem. No hand-holding, no toy examples.
How each challenge works
Brief, design, solve, defend.
The brief
A real scenario with user stories, acceptance criteria, and hard constraints. No hand-holding, no extra scaffolding.
Two real solutions
Every project comes with two complete solution approaches. Low-traffic vs high-traffic. Pessimistic vs optimistic. Simple vs reliable.
Written tradeoffs
Each solution comes with a short doc explaining the tradeoffs and when each approach is the right answer.
Portfolio-ready repo
Clone the solution, run it with docker compose, break it, fix it, and ship it to your GitHub as a talking point.
Real backend systems with real solution tradeoffs.
Data infrastructure
Resumable uploads, link unfurling, auth as its own service, and reliable async queues.
The resumable uploader
Build an upload service that survives network failures and server restarts with 512MB of RAM.
The link unfurler
Extract metadata from arbitrary URLs. Two approaches, two traffic profiles.
The auth microservice
Stateless JWT auth as its own service. Simple vs secure tradeoffs.
Async queues, done right
Simple queue vs reliable queue with dead letter and idempotency.
High scale
Seat lockers, live auctions, real-time scorecards, and geospatial queries under load.
The seat locker
50K seats, 2M fans, zero double-sells. Pessimistic vs optimistic locking.
The live auction
Real-time bidding over websockets with fairness and no lost updates.
The live scorecard
Push live sports scores to thousands. SSE vs WebSocket.
Geospatial search
Find nearby restaurants. Bounding box vs KNN with PostGIS.
Distributed systems
Event sourcing, idempotent payments, feature flags, and a microservices capstone.
Event-sourced ledger
An immutable log of events you can replay to reconstruct any historical state.
Idempotent payments
Same request twice equals one charge. The Stripe-style idempotency key pattern.
Feature flags at scale
Percentage rollouts, targeting rules, and the kill switch every senior engineer reaches for.
Capstone: microservices mall
Products, cart, orders, payments. Four services, one gateway, docker compose at the top.
Production lifecycle
Hardening, observability, and the on-call story that keeps real systems alive.
API hardening under real load
Rate limits, CORS, helmet, and the defenses every public API needs.
Observability and incident response
Logs, metrics, traces, dashboards, and runbooks that earn their keep at 2 AM.
Alert fatigue and how to avoid it
The right alerts are rare, actionable, and lead to a clear response.
The blameless postmortem
The document that turns an incident into a learning.
Production operations
Container orchestration, secrets, blue-green, and the portfolio story.
Container orchestration
What an orchestrator actually does, and when you need one.
Secrets management
Never commit a secret. Inject them at runtime, rotate them on a schedule.
Blue-green and canary deploys
Two deployment strategies that make rollback a one-minute operation.
Portfolio reflection
Turn these projects into the interview-winning artifact they deserve to be.
Workshop Curriculum
What you'll build in this hands-on workshop.
Anyone can recite patterns. Senior engineers defend tradeoffs.
AI can describe event sourcing.
Definitions, sample code, blog summaries.
AI cannot give you:
- Real reps designing under hard constraints
- The instinct to spot a contention bottleneck before it ships
- The judgement to choose between two valid approaches and own the choice
- A portfolio of runnable projects you can defend in an interview
That comes from building real systems and writing down why you built them that way.
Learn From Someone Who Actually Does This
I am the Head of Engineering at Jobbatical (EU Tech), with 8+ years of leadership and 15+ years of total experience in the software industry.
"Most engineers are not blocked by ability, but by lack of real system ownership."
Guest Sessions From Engineers at
Live sessions on System Design, Career Growth, and Interview Preparation.
Get Full Access
Invest in your career. It pays back 100x.
Frequently Asked Questions
How is this different from the Backend Masterclass?
Do I need backend experience already?
Why two solutions per project?
Will these projects look good in interviews?
When you finish:
Stop reading about distributed systems. Build them and defend them.
Enroll in this Course
Enter your email to proceed to checkout.
Includes lifetime access to the interactive course.