Microservices: plainly explained.

Microservices are an architectural style where an application is split into small, independent services, each responsible for one business capability (billing, authentication, search), each with its own codebase, database, and deployment pipeline, communicating with the others over the network, usually through APIs. This is the opposite of a monolith, where all the features live in a single codebase and get deployed together as one unit. Companies like Netflix and Amazon popularized the approach to let hundreds of teams ship independently without blocking each other.

The goal is organizational as much as technical: smaller, focused codebases are easier for a single team to own, test, and deploy on its own schedule, without waiting for the rest of the application to be ready.

Services typically talk to each other over HTTP (REST or GraphQL) or through an asynchronous message queue, so that one service failing does not necessarily bring down the others. A simple REST call between two services might look like this:

// order-service calls inventory-service
const response = await fetch('https://inventory.internal/api/stock/sku-123');
const { available } = await response.json();

if (!available) {
throw new Error('Out of stock');
}

In production, this direct call is often routed through an API gateway that handles authentication, rate limiting, and load balancing across service instances, and each service scales independently based on its own traffic.

• API gateway: a single entry point that routes requests to the right service and centralizes authentication and rate limiting.
• Service discovery: a registry that lets services find each other's network location automatically as instances start and stop.
• Event-driven communication: services publish events to a queue (e.g. an order-placed event) instead of calling each other directly, decoupling them further.
• Database per service: each service owns its data store, avoiding a shared database that would couple services back together.

• Do not split into microservices before the team and the product are large enough to need it; a premature split adds network overhead and operational complexity without benefit.
• Design each service around a clear business capability, not around a technical layer, so a single team can own it end to end.
• Invest in monitoring, tracing, and logging from day one, since debugging a request that spans five services is far harder than debugging a monolith.
• Version APIs between services carefully; a breaking change in one service can silently break every service that depends on it.

Microservices let large organizations ship faster by letting teams deploy independently, scale only the parts of the system under real load, and pick the best tool or language for each service rather than being locked into one stack. The trade-off is operational complexity: more moving parts, more network calls, and a real need for automation (CI/CD, containers, orchestration) to keep everything reliable. For a small team or an early-stage product, a well-organized monolith is usually the faster, cheaper starting point.

We start most projects with a well-structured monolith and split out microservices only once a real scaling or team bottleneck justifies the added complexity, for example isolating a heavy background job or a service that needs to scale independently from the rest of the app. This keeps early development fast while leaving the door open to a distributed architecture as the product grows. See our web apps service for how we architect back-end systems.