Microservices Architecture Simulator

Overview

A microservices architecture splits an application into small services that each own one job and talk over the network. This simulator models a small shop built that way: an API gateway in front of user, product, cart and order services. When you start the simulation, calls travel between the services, and each service shows its CPU, memory, latency and status, healthy, degraded or down. A degraded or down service lowers the success rate of the calls that involve it, and the failures add up in the overall request counters, which makes the main cost of microservices visible: every network call is a new way to fail. Each service gets a fixed share of the traffic and each instance handles a set amount, so clicking a service shows its load as a share of capacity. The user service starts overloaded, with high CPU, slow responses and failing calls; scaling it up spreads the same load over more instances until it recovers, and scaling a busy service down does the opposite. A short tutorial walks you through it, and the notes below cover when a modular monolith is the better choice.

Try this

1. Follow the tutorial: select a service, start the simulation and scale the service.
2. Start the simulation and watch the overall request totals as calls travel between the services.
3. Select the user service, which starts overloaded, and scale it up until its load drops below capacity and the success rate recovers.

Frequently asked questions

What is an API gateway?

A single entry point in front of your services that routes requests to the right one and handles shared concerns such as authentication, rate limiting and TLS termination.

When should you avoid microservices?

When the team is small, the domain is not yet well understood or the system is simple. Microservices add network failures, distributed debugging and deployment overhead, so a modular monolith is often the better start.

How do you stop one failing service from taking down the others?

Use timeouts on every call, retries with backoff, circuit breakers that stop calling a failing service, and fallbacks, so a dependency failure degrades one feature instead of the whole request.