Vom Monolithen zu Microservices
Welche Kompromisse Microservices wirklich eingehen, wann sich die Aufteilung lohnt und warum 'mit einem Monolithen anfangen' meist richtig ist.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
BookVault is a monolith: one deployable app containing the catalog, lending, security, everything. That's not an insult - it's often the right design. This module is about when and how to split a monolith into microservices, and, just as importantly, when not to.
What microservices actually are
Instead of one application, you run several small, independently deployable services, each owning one business capability and its own data:
The single entry point (Spring Cloud Gateway). Routes each request to the right service and handles cross-cutting concerns like auth and rate limiting.
BookVault might become a catalog service, a lending service, and a notification service, behind an API gateway, coordinated by shared infrastructure (discovery, config, a broker).
The real trade-off
Microservices buy you independent scaling and deployment and clear team ownership. But they charge a steep price you pay every day:
- Distributed-systems complexity - network calls fail, latency is real, data is spread across services with no cross-service transaction.
- Operational overhead - many deployments, service discovery, config, monitoring, tracing.
- Eventual consistency - you can't just
@Transactionalacross services.
A single restaurant kitchen (the monolith) is simple: one team, one space, shared everything. A food court (microservices) lets each stall specialize, open, and scale on its own - but now you need shared plumbing, a common seating area, signage, and coordination between stalls. The food court wins at scale and variety; for a small café, it's needless overhead. Choose by how big and varied the operation really is.
The honest default: start with a monolith
Most teams reaching for microservices don't have the scale or team size to justify the cost - and end up with a distributed monolith: all the complexity, none of the independence. The widely-shared advice is:
Build a well-structured monolith first. Split out a service only when a concrete need - independent scaling, a separate team, a different technology - justifies it.
BookVault stays a monolith in this course precisely because that's the right call for its size. The rest of this module gives you the Spring Cloud tools for when the split is warranted.
A modular monolith gets you most of the way
Clean module boundaries inside a monolith deliver most of the maintainability benefit with none of the network cost. Get the boundaries right first; you can always extract a service later. (Spring Modulith, in the next module, helps enforce those boundaries.)
For each scenario, argue whether extracting a microservice is justified:
- BookVault's notification sending occasionally spikes and you want to scale just that part.
- A two-person team wants to split BookVault into six services "to be modern."
- One capability needs a totally different tech stack and an independent release cadence.
What's the widely-recommended default when considering microservices?
Key takeaways
- Microservices are several small, independently deployable services, each owning one capability and its own data, behind a gateway.
- They buy independent scaling/deployment and team ownership but cost distributed-systems complexity, operational overhead, and eventual consistency.
- The default advice: start with a well-structured monolith; extract a service only for a concrete need (scale, team, technology).
- A modular monolith delivers most of the maintainability benefit without the network cost.
- BookVault stays a monolith because that's right for its size; this module covers the tools for when a split is justified.