A growing product company eventually discovers that each application has built its own version of identity, payments, notifications, administration and observability. The duplication feels harmless when products are small. It becomes expensive when teams must fix the same security flaw, provider change or operational issue repeatedly. The obvious response is centralization, but centralization can create a different failure: one giant platform that knows too much about every business.
The distinction that matters is between capability and domain. An identity service can provide authentication and tenant boundaries without deciding how an event booking works. A payment layer can route and reconcile transactions without owning the business meaning of an invoice. Shared foundations should provide stable contracts; products should retain their rules, data authority and independent release schedules.
This separation is neither microservices for their own sake nor a mandate to distribute every feature. It requires architectural judgment about which concepts are genuinely common. A shared service needs explicit ownership, versioning, graceful degradation and real adoption documentation. When a central dependency fails, critical product activity should not fail merely because an administrative console is unavailable.
A practical test is to ask whether a new product can be introduced without copying infrastructure or negotiating changes to unrelated products. Then ask whether one product can evolve its business logic without forcing all others to deploy. The goal is not maximum reuse; it is shared leverage with independent accountability.