Spring Boot microservices, split where the business splits

Microservices trade simplicity in the code for complexity in the system. Every service boundary becomes a network call that can be slow or fail, every service needs its own pipeline, monitoring and on-call owner, and data that used to sit in one transaction is now spread across several. That trade is worth making when different parts of the platform change at different speeds, need to scale separately, are owned by different teams, or carry different compliance and availability requirements.

It is rarely worth making for a new product with one team and an unsettled domain. There we usually recommend a modular monolith: one deployable Spring Boot application with module boundaries enforced in code — Spring Modulith can verify that modules only talk through their public APIs — so that a module can be lifted out into its own service later, once the boundary has proved itself.

An architecture review answers the question for your system before any code moves. We look at how the domain is organised, how often each part changes, where load and failures concentrate, what the team can operate, and what the regulators expect, and recommend services, a modular monolith or a mix — with the reasoning written down so the decision can be revisited.

• Parts of the system change on different schedules, or are owned by different teams
• One workload — ingestion, search, pricing — needs to scale far beyond the rest
• A failure in one area must not stop the others, such as alerting during a batch load
• Different parts carry different compliance, audit or availability requirements
• Several clients — web, mobile, partners — consume the same business capabilities

Good boundaries come from the domain. We run short workshops with the people who use and run the system to map its business events, the decisions taken on them and the language each group uses, and draw bounded contexts where that language and ownership change. A boundary drawn this way is stable: the business rarely reorganises the difference between pricing and booking, whereas a boundary drawn around a database table moves every time the schema does.

For BizGlobe, the boundaries were the travel verticals themselves — flights, hotels, trains, visas, insurance, cabs and cruises — each a Spring Boot service with its own suppliers, rules and release cycle, behind one API layer that serves both the React web app and the React Native mobile apps. Adding a vertical meant adding a service, not reopening the others, and the shared API layer cut backend duplication across web and mobile by 70 %.

Size follows ownership. A service should be small enough for one team to understand and change on its own, and large enough that a single business change rarely touches more than one of them. When a feature regularly needs coordinated releases across three services, the boundary is wrong, and we would rather merge them than add more coordination.

The rule that does most to keep microservices independent is that each service owns its data and no other service reads its tables. Other services get the data through the owning service's API or from the events it publishes. Shared databases are the most common reason a microservices platform ends up as a distributed monolith, where nothing can be changed or deployed on its own.

Work that spans services cannot use one database transaction, so we design it as a saga: a sequence of local transactions, each publishing an event that triggers the next, with a compensating action for each step if a later one fails. Simple flows are choreographed through events; flows with many steps or strict audit needs get an orchestrator that records where every instance stands. To make sure an event is published exactly when the database change commits, services write events to an outbox table in the same transaction and a relay — a scheduled publisher or change-data capture with Debezium — sends them to the broker.

Reporting and search are given their own read models rather than queries across service databases. Events feed a reporting store or a search index such as Elasticsearch, which is how the Royal Monetary Authority of Bhutan's EWS-Plus returns sub-second search across millions of financial records without loading the systems that own the data.

Services call each other synchronously — REST with an OpenAPI contract, or gRPC between internal services where latency matters — only when the caller genuinely needs the answer to continue. Everything else is an event: an order placed, a payment received, a risk threshold crossed. Events let the publisher carry on without knowing who listens, and let a new consumer be added without changing the publisher.

For the broker, Kafka suits high-volume event streams, replay and multiple independent consumers of the same events; RabbitMQ suits task queues, routing and request-reply with lower operational weight. Either way, consumers are idempotent so a redelivered message does no harm, failed messages go to a dead-letter queue that someone monitors, and event schemas are versioned so producers and consumers can be released independently.

At the edge, Spring Cloud Gateway routes requests, validates tokens, applies rate limits and hides the internal topology from clients. Where web, mobile and partner clients need different views of the same capabilities, each gets a thin backend-for-frontend instead of one API that serves everyone badly — in Spring Boot, or in Node.js when the front-end team owns it. Contract tests with Spring Cloud Contract or Pact run in every pipeline, so a change that would break a consumer fails the build instead of production.

In a distributed system something is always failing somewhere, so every call between services is written to expect it. Each call has a timeout; retries use backoff and only apply to operations that are safe to repeat; circuit breakers stop a struggling service from being flooded by callers; bulkheads keep one slow dependency from exhausting the threads everything else needs. Resilience4j provides these through Spring Cloud CircuitBreaker, and each one is tested by deliberately failing dependencies in a test environment.

Observability is built in from the first service, not added after the first incident. Spring Boot Actuator and Micrometer publish metrics; Micrometer Tracing with OpenTelemetry propagates a trace across every service, queue and database a request touches; logs are structured and carry the trace ID, so an engineer can go from an alert to the exact failing call in minutes. Dashboards and alerts are defined against service-level objectives — latency, error rate, queue lag — that the business has agreed matter.

• Timeouts on every remote call, retries with backoff only where operations are idempotent
• Resilience4j circuit breakers, bulkheads and rate limiters, tested by injecting failures
• Micrometer metrics and OpenTelemetry traces across services, queues and databases
• Structured logs with trace IDs, shipped to one place your team already uses
• Alerts on agreed service-level objectives, not on every CPU spike

CareEdge's early-warning system is built as Spring Boot microservices behind an Angular 14 dashboard. It ingests borrower data from financial statements, transaction histories and credit bureaus, applies a rule engine whose thresholds risk officers configure themselves, and raises real-time alerts. It integrates with five core banking systems over secure REST APIs without disrupting them, processes more than 100,000 borrower records a day with sub-three-second query response, and cut NPA escalation response time by 60 %. How the system is put together is written up in Building an Early Warning System on Spring Boot.

Bank of Baroda's early-warning system started as a monolith built for one bank's data. After the mergers with Vijaya Bank and Dena Bank we split it into Spring Boot microservices on Java 11 behind Liferay DXP 7.4, with data-ingestion pipelines for the merged entities' systems and an RBI-compliant maker-checker workflow. The platform absorbed three times the data volume, risk-review cycles fell from two days to four hours, and no data was lost in the move — the route from monolith to services is described on our Spring Boot migration page.

Outside banking, BizGlobe's seven travel verticals run as separate Spring Boot services behind one API layer, and the platform went live on web, iOS and Android within a four-month development cycle.

Security is enforced at two layers. The gateway authenticates every request with OAuth 2.0 and OpenID Connect and passes a token inward; each service is an OAuth 2.0 resource server that checks the token and applies its own authorisation rules, so a compromised neighbour cannot simply call it. Service-to-service traffic is encrypted, secrets come from a vault or the cloud provider's secret store rather than configuration files, and every image is scanned for vulnerable dependencies in CI. For banks and regulators the audit trail — who did what, through which service — is part of the design.

Each service has its own repository or module, its own pipeline and its own release. Images are built by Jenkins or GitHub Actions and deployed with blue-green or canary releases, using Actuator's liveness and readiness probes and Spring Boot's graceful shutdown so that deployments drop no requests. Kubernetes — EKS, AKS, GKE or on-premise — is the default once there are many services; a handful of services run perfectly well as containers on virtual machines or a managed container service, and we do not add Kubernetes to a platform that does not need it.

Cost is driven by the number of services and teams, the number of systems to integrate, how much existing data and behaviour has to move, the availability and compliance targets, and whether the platform foundations — gateway, pipelines, observability, security — already exist. Those foundations are built once, with the first service, and every later service reuses them. We start with an architecture review that ends in a service map, the foundations needed and a fixed-price proposal for the first release.