Free lesson · Microservices Interview
Welcome - Why We Built This Course
Welcome - Why We Built This Course
I have conducted over 300 interviews at Amazon. Principal-level system design rounds, mostly. The kind where you hand someone a vague problem - "design a notification platform" or "architect a food delivery system" - and watch how they think for 45 minutes.
Here is what I have seen, consistently, across hundreds of those sessions.
Candidates know the patterns. They can name the Saga pattern, the Circuit Breaker, the Strangler Fig. They have read the blog posts, watched the conference talks, memorized the vocabulary. And then, when I ask them why they would decompose a system into services at this particular boundary instead of that one - silence. Or worse, a rehearsed answer that does not actually address the constraint I put in front of them.
The gap is not knowledge. It is architectural reasoning under pressure. The ability to take a set of requirements, identify where microservices create value and where they create unnecessary complexity, make decomposition decisions you can defend, and anticipate the data-management and failure-mode consequences of those decisions - all within a 45-minute conversation with someone evaluating your judgment.
That is what this course teaches.
Interactive animation: Naming the Circuit Breaker or the Saga, versus knowing when a retry with backoff is better or walking the compensation.
Who Is Teaching You
My name is Brandon Carter. I am a Principal Software Development Engineer at Amazon Web Services, on the S3 Distributed Storage Infrastructure team. Before Amazon, I was at Stripe, where I worked on payment infrastructure handling over 100 million transactions per day. I am also an Amazon Bar Raiser - which means I am one of the people who makes the final hire/no-hire decision across interview loops. I have seen what gets candidates hired at the principal level, and I have seen what gets them rejected.
I did not build this course alone.
Emeka Okafor is a Senior Software Engineer at Netflix, on the Data Platform team. He operates the real-time event streaming pipeline that ingests over 8 billion events per day using Kafka and Flink. When this course talks about event-driven architecture, observability, or data infrastructure at scale, Emeka is speaking from the system he operates every day - not from a blog post he read about it.
Nikhil Joshi is a Senior Software Engineer at Google, on the Distributed Systems team working on cross-region data replication for Cloud Spanner. When this course covers consistency models, distributed transactions, or multi-region architecture, Nikhil brings the perspective of someone who builds the infrastructure that other microservices depend on. He also brings something else - the experience of being a strong distributed systems engineer who twice failed Google's system design interview because he could not translate production knowledge into the structured reasoning format interviewers expect. He eventually passed, and the gap he closed is exactly the gap this course is designed to close for you.
Between the three of us, we operate microservices at the companies that pioneered them. Amazon's service-oriented architecture is the origin story of modern microservices. Netflix's infrastructure is the canonical case study in resilience engineering. Google's distributed systems underpin the consistency and coordination primitives that every serious microservices architecture eventually needs. This course is not a summary of what we have read. It is a distillation of what we do.
Why This Course Exists
There is no shortage of microservices content on the internet. You can find pattern catalogs, reference guides, tutorial series, and conference talks that will teach you every pattern in this course by name. Most of them are technically accurate.
Most of them also produce candidates who do this in interviews:
"I would use microservices because they provide independent deployability and scalability."
That sentence is not wrong. It is also not useful. It tells the interviewer nothing about whether you understand the cost of that independence - the distributed transaction complexity, the operational overhead, the debugging difficulty, the organizational restructuring it demands. It tells the interviewer you have memorized the sales pitch, not that you have internalized the engineering tradeoffs.
The gap we kept seeing, across hundreds of interviews between the three of us, was not in vocabulary. It was in reasoning. Candidates could name the Circuit Breaker pattern but could not explain when a simple retry with backoff was the better choice. They could describe the Saga pattern but could not walk through the compensation logic when step four of six fails. They knew event sourcing existed but could not articulate why it was the wrong choice for the specific system they had just designed.
That gap - between knowing the pattern and reasoning about its application - is what this course is designed to close. Every module, every lesson, every exercise is built around the question: given these constraints, what is the right architectural decision, and can you defend it?
Important: This is not a "what are microservices" introductory course. It is an interview-preparation course for experienced engineers. If you are encountering concepts like service decomposition, distributed transactions, or event-driven architecture for the first time, start with our System Design Fundamentals course first. This course builds on that foundation and assumes you have it.
Every module in this course is structured around a simple question: how does this help you demonstrate architectural judgment in a system design interview? The patterns matter. The implementation details matter. But what matters most is your ability to reason about when to apply them, why they solve the problem at hand, and what you are trading away by choosing them.
That is what gets senior engineers hired. That is what this course trains.
Interactive animation: Four questions for every pattern: when, why it solves the problem, what you trade away, and can you defend it.
What You Will Be Able to Do
By the time you complete this course, you will be able to:
- Decompose a system into well-bounded microservices and defend every boundary decision with a clear rationale
- Design data management strategies across service boundaries - including sagas, event sourcing, CQRS, and the outbox pattern - and explain the consistency tradeoffs of each
- Anticipate and design for failure modes that interviewers use to stress-test your architecture - cascading failures, partial outages, data inconsistency
- Evaluate whether a problem actually needs microservices, or whether a modular monolith is the better answer
- Architect migration strategies from monolith to microservices with phased risk management
- Reason about microservices at scale - what changes when you go from 10 services to 1,000, and what organizational and platform engineering concerns emerge
These are not theoretical capabilities. They are the specific skills that system design interviewers at L5 through L7 evaluate. We have been on both sides of that table. This course puts you on the stronger side.
How to Approach This Course
Interactive animation: Two weeks or two months - Modules 01, 02, 05, 06 and 13 first, or the whole course front to back.
One thing before we begin. This course is dense. It covers 14 modules of material that ranges from foundational decomposition to advanced operational concerns. You do not need to complete it linearly if that does not match your timeline.
If you have an interview in two weeks, start with Module 01 (Foundations), Module 02 (Decomposition), Module 05 (Data Management), Module 06 (Resilience), and Module 13 (Case Studies). Those five modules cover the highest-frequency interview territory. Come back for the rest when you have more time.
If you have two months, go front to back. The modules build on each other, and the case studies in Module 13 will land differently after you have absorbed the patterns in Modules 04 through 11.
Either way - do the exercises. They are designed as interview simulations, not busywork. The exercise in Module 03 on migration planning is the kind of question that shows up in principal-level rounds at Amazon almost verbatim. The data management exercises in Module 05 test exactly the kind of tradeoff reasoning we discussed above.
Let us get started.
Interactive animation: Practice that answers back: reading does not make you good at interviews, so do the exercises built as interview simulations.