Spring Boot microservices

Should this even be multiple services?

Answer this before anything else in this skill. A modular monolith — one deployable, cleanly separated packages/modules per domain, per spring-boot-architecture's layering — is the right default for most systems, including many that will eventually need to split. Split out a service only when it has a genuinely independent reason to: a different scaling profile (one part of the system needs 50x the compute of the rest), a different release cadence a team actually needs, or a hard team-ownership boundary. A "distributed monolith" — several services that share one database, deploy in lockstep, and call each other synchronously in a long chain — has all the operational cost of microservices (network calls, partial failure, deployment coordination) with none of the independence benefit. If a proposed split doesn't remove a shared database or a lockstep-deploy requirement, question whether it's actually solving anything.

Spring Cloud version compatibility — check this before adding the BOM

Spring Cloud ships as dated "release trains" (e.g., 2025.1.x, codename Oakwood), each compatible with a specific Spring Boot line — they are not interchangeable by picking the newest of each independently. On this skill set's Spring Boot 4.1 baseline, the 2025.1.x train is the compatible one; always check the current compatibility matrix before pinning a train, since trains and Boot versions both ship on independent six-month cycles and a mismatch is a real, frequent-enough failure mode that Spring Cloud ships a compositeCompatibilityVerifier that fails fast at startup with the required version named in the exception — read that message before assuming it's a code bug.