Grokking Microservices for System Design Interviews

0% completed

Module Introduction

  1. What This Module Covers
  1. The Lessons
  1. Two Terms Used Throughout
  1. Before You Start

1. What This Module Covers

Suppose you have decided to split a system into services. The next question decides whether that split works. Where do the lines go?

Each line you draw is a boundary. A boundary says what one service owns and where it stops. Boundaries are the one part of a microservices system you cannot fix later with a clever pattern. A bad retry policy is a config change. A bad boundary is a migration project.

Interviewers know this. That is why "how would you split this system?" gets asked far more often than any pattern definition. Drawing boxes is easy, and every candidate draws roughly the same boxes. What gets scored is your reasoning. Why these boundaries? What data does each service own? What would make you merge two boxes back together?

💡 In the interview, say your reasons out loud as you draw each line. The boxes earn no points on their own. The reasoning behind each line does.

2. The Lessons

Question the lesson answersLesson
What is a bounded context, without the jargon?Bounded Contexts in Plain Words
What heuristics actually produce good boundaries?Drawing Service Boundaries
How big should one service be?How Big Should a Service Be?
How do you split an existing monolith safely?Splitting a Monolith: The Strangler Fig
What do boundary mistakes look like at scale?The Distributed Monolith and Chatty Services
Can you draw and defend boundaries on a real system?Capstone: Drawing E-commerce Boundaries

3. Two Terms Used Throughout

  1. Coupling. How much one part of the system has to know about, or wait for, another part. Two services are tightly coupled when a change or a failure in one forces a change or a failure in the other. Boundaries exist to reduce coupling. Here is the test. A boundary that does not reduce coupling is just a network hop.
  2. Cohesion. How much the things inside one boundary belong together. High cohesion means everything in the service changes for the same reasons. One old rule runs through this whole module: things that change together stay together; things that change separately can be separated.

4. Before You Start

Pick a system you know well. If you had to split it into exactly three services, where would the lines go? Which line are you least confident about? Keep that answer, because the capstone will give you a method to check it against.

Start with Bounded Contexts in Plain Words. Every microservices interview expects one term from domain-driven design, which is a way of shaping software around how the business itself talks and works. That lesson covers the term, and you will see why it matters for boundaries right away.

Mark as Completed

On This Page

  1. What This Module Covers
  1. The Lessons
  1. Two Terms Used Throughout
  1. Before You Start