Microservices Architecture
Term 31 of 68 in the ERPStack technical glossary
What is Microservices Architecture?
Microservices is an architectural style that structures an application as a collection of small, loosely coupled, and independently deployable services organized around specific business capabilities.
Microservices Architecture at a glance
- Unit
- 1 service, 1 database, 1 deploy pipeline — sharing a database re-couples the 2 services
- Communication
- Synchronous REST or gRPC for queries; Apache Kafka events for state changes
- Consistency
- No distributed transaction — use the Saga Pattern with compensating steps
- Operational tax
- N services need N pipelines, plus OpenTelemetry tracing to follow 1 request across them
- Built with
- TypeScript 5.9 services on Docker and Kubernetes, Apache Kafka for events, PostgreSQL 18 or MongoDB Atlas per service, Redis for caches, GitHub Actions per pipeline, Sentry and OpenTelemetry
- Numbers that matter
- 1 database per service; 1 request may cross 6 services; 0 distributed transactions; 2 pipelines minimum once you split 2 services
- Compare with
- Monolithic Architecture, and a modular monolith as the usual middle ground
- Runtime toolchain
- Docker, Kubernetes, Redis, Apache Kafka, Terraform, GitHub Actions, Sentry and OpenTelemetry Observability
- Where the boundary comes from
- Business capability, not layer: an ERP splitting into finance, inventory and logistics services, each owning 1 Postgres schema nobody else writes to.
- Team shape
- 1 service per team able to deploy it. 6 services owned by 2 teams means 3 of them wait on somebody else — the coupling the split was supposed to remove.
How Microservices Architecture works in production
The ERPStack approach to Microservices Architecture
We design modular systems that share single code repositories using monorepo setups, combining the developer speed of a monolith with the deployment benefits of microservices.
Frequently asked questions about Microservices Architecture
When is Microservices Architecture the wrong choice?
Early, and at small scale. Microservices Architecture buys independent deployment and independent scaling, and pays for it with network failure modes, distributed data and a much larger operations surface. If 1 team owns everything and deploys weekly, that trade is negative: you take on the cost and receive none of the benefit. The usual advice — start with a modular monolith and split along proven seams — holds up well.
Why can't 2 microservices share a database?
Because a shared database re-creates the coupling the split was meant to remove. In Microservices Architecture, if service A can read service B's tables, then B can no longer change its schema without coordinating a release with A, and you now have distributed code with monolithic data — the worst of both. Ownership of storage is what makes a service boundary real.
How do transactions work across services?
They do not, in the database sense. Microservices Architecture replaces a single ACID transaction with the Saga Pattern: a sequence of local transactions, each with a compensating action that undoes it if a later step fails. That means designing the business rollback — a refund, a stock release, a cancellation — as a first-class operation rather than assuming the database will unwind everything for you.
What observability does a service split require?
Distributed tracing, from the start. In Microservices Architecture 1 user action may touch 6 services, and a log file per service cannot reconstruct that path. OpenTelemetry propagates a trace identifier through every hop so a slow request can be attributed to the specific span responsible. Without it, debugging degrades into correlating timestamps across machines by hand.