Free through lesson 3

Messaging & Microservices for Beginners

From spotting the real limits of a monolith, to drawing boundaries, to the armor every synchronous call needs (timeouts, retries, circuit breakers), Kafka topics and offsets, sagas and the outbox, and finally the decisions "don't split" and "go back to the monolith." Over 30 lessons, you'll get to the point where you can estimate, in numbers, what gets harder when you split. Every output shown comes from actually running Kafka 4.3.1 and Node.js 26.9 processes and measuring them.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are grouped into 6 chapters. Working through them in order from chapter 1 is recommended, but feel free to jump to whatever interests you. * This course has more prerequisites than any other course on this site. Docker for Beginners is required, and it assumes you've finished API Design for Beginners, Redis & NoSQL for Beginners, and Monitoring & Observability for Beginners. * Lessons that run multiple services or a broker can't run in the browser, so try them with Node.js and Kafka on your own machine. Short snippets that only check the decision logic can be run right in the browser.

Chapter 1 — What Happens When You Split (lessons 1–5)

First, we look at all the work that appears the moment you split. By the end, you'll have the evidence to say with confidence, "We're better off not splitting."

Before Splitting, List the Reasons Not To

Microservices are a means, not a goal. Weigh what you gain against the work you take on, and gather the evidence to say "a monolith is fine for now."

Free

Where a Monolith's Limits Actually Show Up

Not as "it's heavy," but as deploys, blast radius, and teams waiting. Tell apart limits that splitting fixes from ones it doesn't.

Free

Function Calls vs. Calls Over the Network

The same work gets 2000x slower across a boundary, and "it failed" becomes a new possible outcome. We measure it with two local processes.

Free

Where to Draw the Boundaries

Split along business seams, not technical layers. Get it wrong and one screen makes 100 calls. We measure it.

The Network Fails: The New Problem of Partial Failure

We actually trigger a case where one side succeeds and the other fails. The moment the monolith's one-line ROLLBACK becomes your job.

Chapter 2 — Connecting Synchronously (lessons 6–10)

We add, one at a time, the armor you always need when calling a service directly: timeouts, retries, and circuit breakers. By the end, you'll have built a setup where a single failure doesn't spread to everything.

Etiquette for Service-to-Service HTTP

Reusing connections or not makes a 2.8x difference. Unlike public APIs, the differences lie in how long compatibility must last and how you hold connections.

gRPC and Calls with a Schema

Types come straight from the proto. On localhost, the speed difference was within the noise. We measure it and see the real reason to pick gRPC.

Setting Timeouts

Without a limit, a slow callee drags the caller down too. We hit a callee that's 5 seconds slow with 3 different settings and measure.

Retries Amplify

If each of 3 chained services retries 3 times, the deepest one gets 27 requests. We start 4 real processes and count.

Circuit Breakers: Stop Calling

We walk through the closed, open, and half-open states and count how many of 16 calls were blocked.

Chapter 3 — Connecting Asynchronously (lessons 11–18)

We stop calling and switch to streaming events instead. You'll start Kafka on your machine and see topics, partitions, offsets, and consumer groups in action.

Stop Calling: Queues vs. Logs

A queue deletes what you take; a log keeps what you read. Both are "async," but the design differs. We run a consumer added later on Kafka.

Starting Kafka and Creating a Topic

In KRaft mode there's no ZooKeeper, just one process. Start it locally, create a topic, and inspect what's inside.

Partitions: The Unit of Parallelism and Ordering

The key decides the destination. The same key goes to the same partition, and order is kept only there. Includes a measurement of that guarantee breaking when you add partitions.

Offsets and Consumer Groups

How far you've read is a number per group. Add consumers and the partitions are shared out; the extra one sits idle. We measure it.

Producers: Acks and "I Thought I Sent It"

We measure the 3 acks levels with 50,000 messages each, and honestly note that a single-node local setup shows no difference.

Consumers: When to Commit

When you record the offset decides whether you lose messages or process them twice. We run a consumer that never commits and see.

How Far Is Ordering Guaranteed?

You only read in send order within a partition. We send 9 messages to 3 partitions and look at the order they're read.

Reprocessing and Poison Messages

Rewind the offset and you can reread, but side effects run twice too. We also decide how to route around one broken message that stalls the queue.

Chapter 4 — Keeping Data Consistent (lessons 19–24)

Once the databases are split, you lose both transactions and JOINs. We plug those holes one by one with eventual consistency, sagas, idempotency, and the outbox.

A Database per Service

Share a database and splitting loses its point. Split it and you can't write JOINs. We start 2 databases and watch that moment happen.

Build a Read Model Instead of a JOIN

Stop querying twice every time and keep a copy shaped for reading. The idea of separating the write and read sides, and its price.

Eventual Consistency: The Lag Isn't Constant

Read right after a write and you get an old value. We measure that window and how the lag grows when you push data in bulk.

Sagas: Undo Exactly as Far as You Got

Pair every step with an undo step. We run 3 orders and count whether the rollback really reverts everything.

Idempotent Consumers: Safe to Receive Twice

Reject at-least-once duplicates on the receiving side. We measure why the "processed" marker and the real update belong in the same transaction.

The Outbox: Writing to the DB and Sending a Message

Saving to the DB and sending an event can't share a transaction. We run the pattern where you write to the same table and someone else sends.

Chapter 5 — Operations (lessons 25–28)

You'll learn to isolate failures across split services and ship them in an order that doesn't break anything. Finally, you'll change the shape of messages safely.

What to Record at Service Boundaries

Distributed tracing proper lives in the Monitoring & Observability for Beginners course. Here we focus only on what to leave behind when crossing a boundary.

Figuring Out Which Service Is at Fault

The difference between 500 and 502/504 decides who gets woken up. We hit 2 implementations with the same failure and measure what each lets you see.

Deployment Order

Ship the receiver first. But make a new field required and things break even in the right order. We try 3 different orders to check.

Changing the Shape of Messages

Adding is safe; renaming breaks things. Worst of all is changing a type: nothing crashes, and you keep charging the wrong amount.

Chapter 6 — Making the Call (lessons 29–30)

We put numbers on the cost of splitting and estimate it. Finally, we face the option of "going back to the monolith" head-on and wrap up the course.

Estimating the Cost of Splitting

Availability drops multiplicatively with each service in a chain. We compute downtime in minutes and turn the decision to split into numbers.

Choosing to Go Back to a Monolith: Wrap-Up

Going back isn't failure. How to do it, and the signs that you should. We close by collecting the decision yardsticks from all 30 lessons.

Once you've finished all 30 lessons, head to the place where your split services actually run: Kubernetes for Beginners. A membership unlocks every course.