advanced
Shared kernel risks
Limit shared libraries and models because every shared kernel can turn independent services back into coordinated release units.
A shared kernel — common library, DTO package, or ORM models used by many services — recreates compile-time and release coupling. One breaking change forces coordinated deploys, defeating microservice independence.
Limit shared code to truly stable, rarely changing primitives: IDs, money types, tracing helpers — not business workflows.
On interviews: argue what belongs in a shared library versus a copied adapter; describe versioning strategy for internal packages.
Common pitfalls: "common" module that grows business logic; publishing events defined only in shared JARs; no semver for internal libs.
The trade-off is flexibility versus complexity—know when the simpler path is enough.
Checklist:
- Audit shared packages for business logic creep.
- Version internal libraries with compatibility guarantees.
- Prefer duplication over wrong abstraction early.
- Replace shared kernels with published contracts.