Module Introduction

1. What This Module Covers

Boundaries decide what the services are. Communication decides how they behave.

This is where interview designs are won or lost. Interviewer write-ups agree on one point. Designing how services talk matters at least as much as choosing the services themselves.

Here is why. Every communication choice quietly sets three properties of your system.

• Latency. How long the user waits for an answer.
• Availability. Whether the system still works when one service is down.
• Consistency. When and whether other services see a change after it happens.

You never announce these properties out loud. You set them the moment you draw an arrow between two services. The interviewer will ask about them later, and a careless arrow gets expensive.

This module gives you the decisions in the order you actually make them.

1. The first choice, sync or async. Does the caller wait?
2. The protocol choice. REST, gRPC, or GraphQL.
3. The machinery for async work. Brokers and pub/sub.
4. The coordination style for multi-step flows. Who drives the steps.
5. The front door, where clients meet the system.

💡 Interviewers rarely ask "is this call sync or async?" straight out. They ask what happens when the payment service gets slow. Your answer was already decided by the arrows you drew.

2. The Lessons

Each lesson answers one question you will face in a real interview.

3. Two Terms Used Throughout

1. Temporal coupling. Both services have to be up and answering at the same moment, or the operation fails. That is temporal coupling. Think of a phone call. If the other side does not pick up, nothing happens. Synchronous calls create temporal coupling, and queues remove it.
2. At-least-once delivery. This is the standard promise of brokers and retries. No message is lost, but some arrive more than once. The moment your design says "queue," it also says "duplicates exist." Your consumers must be safe to run twice on the same message.

Much of this module is about deciding where temporal coupling is acceptable. Making consumers safe to run twice gets a full lesson later in the course.

4. Before You Start

Take the e-commerce boundaries from the previous capstone. Look at every arrow you would draw between two services. For each one, ask a single question. Does the caller need the answer before it can carry on?

Now count how many arrows truly need a synchronous answer. Write that number down. Most people's count drops as the module goes on.

Start with Sync vs. Async. It is the one choice every other lesson in this module builds on.