35m
Advanced
What belongs on the server, what stays on the client, and how to avoid waterfalls.
Alex Rivera
Senior Cloud Architect @ Developer X
Understanding the topology.
Start with bounded contexts, not with folders. Draw the user, order, and notification services as independently deployable units. The API gateway is the only public entry; everything else speaks over an internal network. If two services share a database, they are not two services yet.
Node, Docker, and CLI tools.
Install a current LTS Node, Docker Desktop or Engine, and Compose. Pin versions in a .nvmrc and a compose.yaml so onboarding is a clone-and-up, not a wiki page. Keep secrets in a local .env that is gitignored; never bake keys into images.
Routing requests to services.
The gateway authenticates, rate-limits, and routes. It should not contain business logic. Health checks on each upstream keep a failed service from taking the whole surface down. Test a profile request through the gateway before you add queues.
gateway.sh
# Test the User Service via Gateway
$ curl http://localhost:3000/users/profile
{"status": "success", "data": {"id": 1, "name": "Alice"}}RabbitMQ integration.
Synchronous REST is fine for reads. Writes that other services must react to belong on a queue. Publish an event after the source of truth is committed, consume with at-least-once delivery, and make handlers idempotent. Start with one exchange and one consumer — do not invent a bus you cannot debug.
Writing Dockerfiles & Compose.
One process per container, a non-root user, and a multi-stage build so production images stay small. Compose should boot the gateway, two services, and the broker with a single command. When that works locally, the same Dockerfiles are what you ship to the cluster.
Continue learning
Browse more hands-on walkthroughs from the same team.
Our cloud architects can help you design, containerize, and operate a microservices platform.