🧩 Weekend Project: Build a Microservices-Based Application

The Goal

Build the backend of a small online store as a set of independent services rather than one big program. A Product service owns the catalog and inventory. An Order service turns a cart into a paid order. A User service owns accounts and authentication. A Notification service emails customers when things happen. Each runs in its own container, keeps its own database, and could — in principle — be written by a different team, deployed on its own schedule, and scaled on its own. In front of them sits an API gateway: the one address a client ever calls. The gateway checks who you are, forwards your request to the right internal service, and sometimes stitches several services' answers into one response.

The two communication styles are the heart of the exercise. When the gateway needs an answer right now — "show me this product" — it makes a synchronous REST call and waits. But when an order is placed, the Order service shouldn't sit and wait for an email to be sent, an invoice to be generated, and a warehouse to be pinged. Instead it publishes an event — "an order was placed" — to a message broker and moves on. Other services subscribe and react on their own time. That's the difference between a phone call and a group chat, and knowing which to reach for is what separates a distributed system that stays up from one that topples when any single piece hiccups.

Prerequisites

This capstone pulls together nearly everything the course taught — Express APIs, databases, async JavaScript, Docker, and the architecture ideas from earlier this week. Before you start, make sure you're comfortable with:

You'll need Docker Desktop (or Docker Engine + the Compose v2 plugin) and Node.js 20+ installed locally for iterating on individual services. Verify:

# Confirm your toolchain before you build
docker compose version   # => Docker Compose version v2.x.x  (a SPACE, not a hyphen)
node --version           # => v20.x or newer
npm --version

Required Features Checklist

These are the non-negotiables that make this a genuine microservices application rather than a monolith in disguise. Tick each off as you go.

The Architecture

One door in (the gateway), several independent services behind it, each with a private database, and a broker off to the side carrying events between them. The client never talks to a service directly — it only knows the gateway. The gateway makes synchronous REST calls to services and waits for answers. The services publish and consume asynchronous events through RabbitMQ without waiting on each other.

Two rules give this diagram its shape. First, every service owns its data — there is no shared database that two services both reach into. If the Order service needs a product's price, it asks the Product service; it never queries the Product database directly. That's what keeps services independently deployable: you can change how Product stores its data without breaking anyone else. Second, the gateway is the only public surface. Product, Order, User, Notification, and the broker publish no ports to the outside world; they're reachable only on the internal Compose network, addressed by service name.

Notice the difference in the arrows. The gateway-to-service arrows are labeled REST: a call that blocks until it gets a response. The Order-to-broker-to-Notification arrows are the event path: Order fires and forgets, Notification reacts whenever it's ready. Choosing correctly between these two is the single most important design decision in the whole project.

Monorepo Structure

Keep all the services in one repository (a monorepo) so a single docker compose up can start everything and you can read the whole system in one place. Each service is a self-contained folder with its own package.json, source, and Dockerfile. The gateway is just another folder. The databases and the broker need no folders — you pull them ready-made from official images.

shop-microservices/
├── compose.yaml                 # wires gateway + services + broker + databases
├── .env.example                 # template of the vars Compose substitutes
├── .gitignore                   # ignores node_modules, .env
├── gateway/                     # the single public entry point
│   ├── Dockerfile
│   ├── package.json
│   └── src/
│       ├── index.js             # routing, auth, aggregation
│       └── lib/
│           ├── httpClient.js    # resilient axios wrapper (timeout + retry)
│           └── circuitBreaker.js
├── services/
│   ├── product/                 # catalog + inventory  (owns product-db)
│   │   ├── Dockerfile
│   │   ├── package.json
│   │   └── src/{ app.js, routes/, controllers/, models/, config/ }
│   ├── order/                   # cart to paid order   (owns order-db, PUBLISHES events)
│   │   ├── Dockerfile
│   │   └── src/{ app.js, ..., events/publisher.js }
│   ├── user/                    # accounts + auth      (owns user-db)
│   │   ├── Dockerfile
│   │   └── src/{ ... }
│   └── notification/            # emails on events     (owns notification-db, CONSUMES events)
│       ├── Dockerfile
│       └── src/{ app.js, ..., events/consumer.js }
└── README.md

Stage 1 — Decompose the Domain

Before a line of code, decide where the seams go. The classic mistake is to split by technical layer — a "database service," a "validation service" — which just scatters one feature across many boxes. Instead, split by business capability: each service owns a whole vertical slice of the business, from its API down to its data. Ask, "what are the distinct things this business does?" The answers are your services.

Two heuristics keep your boundaries honest. First, data ownership: a piece of data has exactly one service that can change it. Products belong to Product; nobody else writes to the product database. Second, change together, deploy together: things that always change for the same business reason belong in the same service. If updating the shipping rules always forces a change in two services, you probably drew the line in the wrong place.

Stage 2 — Build One Service

Every service follows the same skeleton — an Express app with routes, controllers, a model, a database connection, and a /health route — so once you've built one, the rest are variations on a theme. Here's the Product service as the template. Start with its entry point:

// services/product/src/app.js
import 'dotenv/config';
import express from 'express';
import mongoose from 'mongoose';
import productRoutes from './routes/product.routes.js';

const app = express();
app.use(express.json());

// Each service mounts its OWN routes under a clear prefix.
app.use('/products', productRoutes);

// Health route — the container's healthcheck and Compose's depends_on rely on this.
app.get('/health', (req, res) => {
  const dbUp = mongoose.connection.readyState === 1; // 1 === connected
  res.status(dbUp ? 200 : 503).json({ service: 'product', status: dbUp ? 'ok' : 'degraded' });
});

const PORT = process.env.PORT || 3000;

async function start() {
  // A service owns its OWN database — note the distinct connection string.
  await mongoose.connect(process.env.MONGO_URL);
  app.listen(PORT, () => console.log(`product service listening on ${PORT}`));
}

start().catch((err) => {
  console.error('product service failed to start:', err);
  process.exit(1); // fail fast so the orchestrator can restart us
});

The model and controller are ordinary Express-and-Mongoose code — the same patterns you built in Weeks 8 and 9. What matters for microservices is the seams: this service exposes a small, deliberate REST surface and nothing else. The checkStock endpoint below exists specifically so the Order service can ask "can I sell this?" without ever seeing the product database.

// services/product/src/controllers/product.controller.js
import Product from '../models/product.model.js';

export async function getProductById(req, res) {
  const product = await Product.findById(req.params.id);
  if (!product) return res.status(404).json({ message: 'Product not found' });
  res.json(product);
}

// Called by the Order service over REST — the ONLY way anyone learns our stock.
export async function checkStock(req, res) {
  const { id, quantity } = req.query;
  const product = await Product.findById(id);
  if (!product) return res.status(404).json({ message: 'Product not found' });
  const qty = Number(quantity) || 0;
  res.json({
    productId: id,
    inStock: product.inventory >= qty,
    availableQuantity: product.inventory,
  });
}

// Reserve stock when an order is placed. Idempotent-friendly and guarded.
export async function reserveInventory(req, res) {
  const { productId, quantity } = req.body;
  const product = await Product.findById(productId);
  if (!product) return res.status(404).json({ message: 'Product not found' });
  if (product.inventory < quantity) {
    return res.status(409).json({ message: 'Insufficient inventory' });
  }
  product.inventory -= quantity;
  await product.save();
  res.json({ productId, remaining: product.inventory });
}

Stage 3 — The API Gateway

The gateway is the system's front desk. Clients only ever talk to it; it decides who's allowed in, forwards each request to the right internal service, and — when a screen needs data from several services — aggregates their answers into one response. Centralizing these concerns means each service can stay small and trusting: it doesn't re-implement auth, and it doesn't need to be reachable from the public internet.

// gateway/src/index.js
import 'dotenv/config';
import express from 'express';
import jwt from 'jsonwebtoken';
import { get, post } from './lib/httpClient.js'; // resilient wrapper (Stage 5)

const app = express();
app.use(express.json());

// Internal services are addressed by SERVICE NAME on the Compose network.
const SERVICES = {
  product: process.env.PRODUCT_URL || 'http://product:3000',
  order:   process.env.ORDER_URL   || 'http://order:3000',
  user:    process.env.USER_URL    || 'http://user:3000',
};

// --- Auth middleware: the gateway is the ONE place tokens are checked. ---
function authenticate(req, res, next) {
  const header = req.headers.authorization || '';
  const token = header.startsWith('Bearer ') ? header.slice(7) : null;
  if (!token) return res.status(401).json({ message: 'Missing token' });
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch {
    return res.status(401).json({ message: 'Invalid token' });
  }
}

// --- Public routes: no token needed. ---
app.post('/api/auth/register', (req, res) => forward(res, () => post(`${SERVICES.user}/users/register`, req.body)));
app.post('/api/auth/login',    (req, res) => forward(res, () => post(`${SERVICES.user}/users/login`, req.body)));
app.get('/api/products',       (req, res) => forward(res, () => get(`${SERVICES.product}/products`)));
app.get('/api/products/:id',   (req, res) => forward(res, () => get(`${SERVICES.product}/products/${req.params.id}`)));

// --- Protected routes: token required. ---
app.post('/api/orders', authenticate, (req, res) =>
  forward(res, () => post(`${SERVICES.order}/orders`, { ...req.body, userId: req.user.id }))
);

// --- Aggregation: one client call, several service calls stitched together. ---
app.get('/api/orders/:id/detail', authenticate, async (req, res) => {
  try {
    const order = await get(`${SERVICES.order}/orders/${req.params.id}`);
    // Enrich each line item with fresh product data from the Product service.
    const items = await Promise.all(
      order.items.map(async (item) => ({
        ...item,
        product: await get(`${SERVICES.product}/products/${item.productId}`),
      }))
    );
    res.json({ ...order, items });
  } catch (err) {
    res.status(502).json({ message: 'Upstream service unavailable', detail: err.message });
  }
});

// Small helper: run an upstream call and relay its result or error status.
async function forward(res, call) {
  try {
    res.json(await call());
  } catch (err) {
    res.status(err.status || 502).json({ message: err.message });
  }
}

app.get('/health', (req, res) => res.json({ service: 'gateway', status: 'ok' }));
app.listen(process.env.PORT || 8080, () => console.log('gateway on 8080'));

Stage 4 — Async Events with RabbitMQ

When an order is placed, several things should happen: the customer gets an email, inventory is adjusted, maybe an analytics counter ticks. If the Order service called each of those synchronously and waited, checkout would be as slow as the slowest downstream step — and if the email server were down, the customer couldn't even place the order. That's backwards. The fix is to publish an event and let interested services react on their own time. This is event choreography: no central conductor commands the steps; each service knows which events it cares about and dances to them.

The Order service publishes to a RabbitMQ exchange the moment an order is saved:

// services/order/src/events/publisher.js
import amqp from 'amqplib';

const EXCHANGE = 'shop.events';         // a topic exchange all services share
let channel;

export async function initPublisher() {
  const conn = await amqp.connect(process.env.RABBITMQ_URL);
  channel = await conn.createChannel();
  // A durable topic exchange survives broker restarts.
  await channel.assertExchange(EXCHANGE, 'topic', { durable: true });
  console.log('order publisher connected to RabbitMQ');
}

// Publish an event under a routing key like "order.created".
export function publish(routingKey, payload) {
  const body = Buffer.from(JSON.stringify(payload));
  // persistent: true asks the broker to keep the message on disk.
  channel.publish(EXCHANGE, routingKey, body, { persistent: true });
  console.log(`published ${routingKey}`, payload.orderId);
}

// services/order/src/controllers/order.controller.js  (excerpt)
import Order from '../models/order.model.js';
import { publish } from '../events/publisher.js';
import { get, post } from '../lib/httpClient.js';

export async function createOrder(req, res) {
  const { userId, items } = req.body;

  // SYNCHRONOUS calls: we need these answers before we can accept the order.
  for (const item of items) {
    const stock = await get(
      `${process.env.PRODUCT_URL}/products/check-stock?id=${item.productId}&quantity=${item.quantity}`
    );
    if (!stock.inStock) {
      return res.status(409).json({ message: `Out of stock: ${item.productId}` });
    }
  }

  const total = items.reduce((sum, i) => sum + i.price * i.quantity, 0);
  const order = await Order.create({ userId, items, total, status: 'pending' });

  // Reserve inventory synchronously (must succeed to hold the order).
  for (const item of items) {
    await post(`${process.env.PRODUCT_URL}/products/reserve`, {
      productId: item.productId, quantity: item.quantity,
    });
  }

  // ASYNCHRONOUS: fire the event and return immediately. Email, analytics,
  // and anything else happen elsewhere, later, without blocking checkout.
  publish('order.created', { orderId: order.id, userId, total });

  res.status(201).json(order);
}

The Notification service never knows Order exists. It only knows it wants messages tagged order.*. It binds a queue to those routing keys and processes each message, acknowledging only after success so nothing is lost:

// services/notification/src/events/consumer.js
import amqp from 'amqplib';
import { sendOrderEmail } from '../services/email.service.js';

const EXCHANGE = 'shop.events';
const QUEUE = 'notification.order';

export async function startConsumer() {
  const conn = await amqp.connect(process.env.RABBITMQ_URL);
  const channel = await conn.createChannel();
  await channel.assertExchange(EXCHANGE, 'topic', { durable: true });

  // A durable queue that survives restarts; bind it to the events we want.
  await channel.assertQueue(QUEUE, { durable: true });
  await channel.bindQueue(QUEUE, EXCHANGE, 'order.created');
  await channel.bindQueue(QUEUE, EXCHANGE, 'order.updated');

  // Process one message at a time so a slow email cannot flood us.
  channel.prefetch(1);

  channel.consume(QUEUE, async (msg) => {
    if (!msg) return;
    try {
      const event = JSON.parse(msg.content.toString());
      await sendOrderEmail(event);
      channel.ack(msg);                 // success: remove from the queue
    } catch (err) {
      console.error('failed to handle event:', err.message);
      // requeue once; in production, route repeat failures to a dead-letter queue
      channel.nack(msg, false, false);
    }
  });

  console.log('notification consumer waiting for order events');
}

Here's the flow end to end. Watch how the customer gets their response the instant the order is saved — the email happens afterward, off the critical path:

Stage 5 — Resilience

In a monolith, calling another module is a function call: instant and infallible. In a distributed system, every arrow in your diagram is a network call that can be slow, fail, or hang forever. If the Product service stalls, a naive Order service waits with it — and callers of Order pile up behind that, until the whole system is jammed by one sick component. This is a cascading failure, and three classic patterns prevent it: timeouts, retries with backoff, and the circuit breaker.

Timeouts and retries

A timeout caps how long you'll wait before giving up. Retries paper over transient blips (a dropped packet, a service mid-restart) — but only a bounded number, with a growing backoff delay so you don't hammer a struggling service. Wrap your HTTP client once and every call inherits both:

// gateway/src/lib/httpClient.js  (and copied into each service)
import axios from 'axios';
import { breaker } from './circuitBreaker.js';

const client = axios.create({ timeout: 3000 }); // give up after 3 seconds

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function request(config, { retries = 2, baseDelay = 200 } = {}) {
  let lastErr;
  for (let attempt = 0; attempt <= retries; attempt++) {
    try {
      // The circuit breaker decides whether we're even allowed to try.
      return await breaker(config.url, async () => {
        const res = await client.request(config);
        return res.data;
      });
    } catch (err) {
      lastErr = normalize(err);
      // Never retry a client error (4xx) — retrying a 404 just wastes time.
      if (lastErr.status && lastErr.status < 500) break;
      if (attempt < retries) await sleep(baseDelay * 2 ** attempt); // 200ms, 400ms
    }
  }
  throw lastErr;
}

function normalize(err) {
  const e = new Error(err.response?.data?.message || err.message);
  e.status = err.response?.status;
  return e;
}

export const get  = (url)       => request({ method: 'get', url });
export const post = (url, data) => request({ method: 'post', url, data });

The circuit breaker

Retrying a service that's genuinely down is worse than useless — you add load to something already on the floor and make every caller wait through the full timeout. A circuit breaker watches the failure rate and, once it crosses a threshold, trips open: for a cooldown period it rejects calls instantly without even trying, letting the sick service recover. After the cooldown it goes half-open, allows one trial call, and either closes again (recovered) or re-trips (still down).

// gateway/src/lib/circuitBreaker.js  — one breaker per target URL
const circuits = new Map();

function circuitFor(key) {
  if (!circuits.has(key)) {
    circuits.set(key, { state: 'closed', failures: 0, openedAt: 0 });
  }
  return circuits.get(key);
}

const THRESHOLD = 5;      // trip after this many consecutive failures
const COOLDOWN = 10000;   // stay open for 10 seconds before a trial call

export async function breaker(key, fn) {
  const c = circuitFor(key);

  if (c.state === 'open') {
    if (Date.now() - c.openedAt < COOLDOWN) {
      // Fail FAST — do not touch the network while the circuit is open.
      const e = new Error('circuit open: upstream unavailable');
      e.status = 503;
      throw e;
    }
    c.state = 'half-open'; // cooldown elapsed: allow ONE trial call
  }

  try {
    const result = await fn();
    c.failures = 0;
    c.state = 'closed';    // success closes the circuit
    return result;
  } catch (err) {
    c.failures++;
    if (c.state === 'half-open' || c.failures >= THRESHOLD) {
      c.state = 'open';
      c.openedAt = Date.now();
    }
    throw err;
  }
}

Stage 6 — Containerize & Compose

Each service ships as its own image. Because every service is a plain Node app, they share one simple Dockerfile — drop an identical copy into gateway/ and each services/* folder:

# services/product/Dockerfile  (identical in every service and the gateway)
FROM node:20-alpine

WORKDIR /app

# Copy manifests first so the dependency layer is cached across code edits.
COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

# Run as the built-in unprivileged user, never root.
USER node

EXPOSE 3000
CMD ["node", "src/app.js"]

Now the keystone: one compose.yaml that declares every service, every database, the broker, the private network they share, and the health checks that keep startup orderly. Only the gateway publishes a host port — everything else is reachable solely by service name on the internal network.

# compose.yaml — the whole system in one file. No obsolete "version:" key.
name: shop-microservices

services:
  gateway:
    build: ./gateway
    ports:
      - "8080:8080"            # the ONLY public door
    environment:
      JWT_SECRET: ${JWT_SECRET}
      PRODUCT_URL: http://product:3000
      ORDER_URL: http://order:3000
      USER_URL: http://user:3000
    depends_on:
      product: { condition: service_healthy }
      order:   { condition: service_healthy }
      user:    { condition: service_healthy }
    restart: unless-stopped

  product:
    build: ./services/product
    environment:
      MONGO_URL: mongodb://product-db:27017/product
    depends_on:
      product-db: { condition: service_healthy }
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--spider", "http://localhost:3000/health"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 15s
    restart: unless-stopped

  order:
    build: ./services/order
    environment:
      MONGO_URL: mongodb://order-db:27017/order
      PRODUCT_URL: http://product:3000
      USER_URL: http://user:3000
      RABBITMQ_URL: amqp://rabbitmq:5672
    depends_on:
      order-db:  { condition: service_healthy }
      rabbitmq:  { condition: service_healthy }
      product:   { condition: service_healthy }
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--spider", "http://localhost:3000/health"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s
    restart: unless-stopped

  user:
    build: ./services/user
    environment:
      MONGO_URL: mongodb://user-db:27017/user
      JWT_SECRET: ${JWT_SECRET}
    depends_on:
      user-db: { condition: service_healthy }
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--spider", "http://localhost:3000/health"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 15s
    restart: unless-stopped

  notification:
    build: ./services/notification
    environment:
      MONGO_URL: mongodb://notification-db:27017/notification
      USER_URL: http://user:3000
      RABBITMQ_URL: amqp://rabbitmq:5672
    depends_on:
      notification-db: { condition: service_healthy }
      rabbitmq:        { condition: service_healthy }
    restart: unless-stopped

  # --- The message broker (official image with a built-in health check) ---
  rabbitmq:
    image: rabbitmq:3.13-management-alpine
    ports:
      - "15672:15672"         # management UI at http://localhost:15672 (guest/guest)
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

  # --- One database PER service. They share an image, not data. ---
  product-db:
    image: mongo:7
    volumes: [ "product-data:/data/db" ]
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 5s
      retries: 5
  order-db:
    image: mongo:7
    volumes: [ "order-data:/data/db" ]
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 5s
      retries: 5
  user-db:
    image: mongo:7
    volumes: [ "user-data:/data/db" ]
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 5s
      retries: 5
  notification-db:
    image: mongo:7
    volumes: [ "notification-data:/data/db" ]
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 5s
      retries: 5

# Each database gets its own named volume — durable, private storage.
volumes:
  product-data:
  order-data:
  user-data:
  notification-data:

Stage 7 — Run & Verify

Create your .env from the template, then bring the whole system up with one command:

# .env  (copied from .env.example, never committed)
JWT_SECRET: replace-with-a-long-random-string

# From the repo root:
docker compose up --build           # build every image and start the system
docker compose up --build -d        # ...or detached, then follow logs:
docker compose logs -f

Watch the boot order in the logs — databases and RabbitMQ report healthy first, then the services, then the gateway. That ordering is your health gates doing their job. Confirm everything is up and healthy at a glance:

docker compose ps
# Every service should read "running", the health-checked ones "(healthy)".

Now exercise the system through the gateway — the only door. A quick end-to-end walk:

// 1) Register a user (public route) → returns a JWT
const reg = await fetch('http://localhost:8080/api/auth/register', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email: 'ada@example.com', password: 'hunter2', name: 'Ada' }),
}).then((r) => r.json());

// 2) Browse products (public route, gateway → product service)
const products = await fetch('http://localhost:8080/api/products').then((r) => r.json());

// 3) Place an order (PROTECTED — send the token; gateway verifies it)
const order = await fetch('http://localhost:8080/api/orders', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${reg.token}`,
  },
  body: JSON.stringify({
    items: [{ productId: products[0]._id, quantity: 1, price: products[0].price }],
  }),
}).then((r) => r.json());

console.log('order placed:', order.id, order.status);
// Meanwhile, the notification service logs that it sent a confirmation email.

# Stop just the notification consumer
docker compose stop notification
# Place an order — checkout STILL succeeds; the event waits in the RabbitMQ queue.
# Now bring it back:
docker compose start notification
# It drains the queued events and sends the delayed emails. Nothing was lost.

Peek at the broker itself — RabbitMQ's management UI shows your exchange, queues, and messages flowing:

# RabbitMQ management UI (default guest/guest on localhost):
#   http://localhost:15672
# Watch the "shop.events" exchange and the "notification.order" queue.

Stretch Goals

Skeleton solid with time to spare? These are the moves that take a learning project toward a production platform. Pick whatever excites you — none are needed to pass the rubric.

Saga sketch — the compensation idea

// Conceptual: a saga coordinates local steps + their undo actions.
async function checkoutSaga(order) {
  const done = [];
  try {
    await reserveInventory(order);           done.push('inventory');
    await chargePayment(order);              done.push('payment');
    publish('order.confirmed', { id: order.id });
  } catch (err) {
    // Roll BACK in reverse by running each step's compensating action.
    if (done.includes('payment'))   await refundPayment(order);
    if (done.includes('inventory')) await releaseInventory(order);
    publish('order.failed', { id: order.id, reason: err.message });
  }
}

Self-Check Rubric

Before you call this done, grade yourself. Aim to answer "yes" to everything in the first two columns — the stretch column is bonus.

Summary & Congratulations

Step back and see what you actually accomplished: you designed a distributed system, chose the right communication style for each interaction, made it survive partial failure, and operated it as one command. The specific services matter less than the shape — a gateway in front, autonomous services owning their data, synchronous calls where answers are needed and asynchronous events where they aren't, and resilience wrapped around every network hop. That shape is the vocabulary of modern backend architecture, and you can now read it, draw it, and build it.

📚 Additional Resources

• Microservices.io — the microservices pattern language (gateway, saga, and more)
• RabbitMQ — official tutorials (topic exchanges, work queues, publish/subscribe)
• Martin Fowler — Microservices, the foundational article
• Microsoft — the Circuit Breaker pattern
• Docker — the Compose file specification
• MDN — HTTP, the protocol under every REST call you made