Shared Service

A Shared Service is a reusable runtime capability consumed by multiple applications, teams, or bounded contexts. Typical examples include identity, notifications, document generation, payments, search, audit logging, and feature configuration.

Why shared services exist

A shared service centralizes a capability when independent implementations would create inconsistent behavior, duplicated operational work, or fragmented governance. It can improve reuse and standardization, but it also creates a dependency that must be designed and operated as a product.

Architectural concerns

• Define a stable service boundary and explicit contract.
• Identify owners, support expectations, and service-level objectives.
• Avoid turning unrelated capabilities into one generic service.
• Plan for tenant isolation, authorization, quotas, versioning, and failure handling.
• Minimize synchronous coupling when consumers can tolerate asynchronous workflows.

Trade-offs

A shared service can reduce duplication, but it can also become a bottleneck, a single point of failure, or a coordination hotspot. Teams should share capabilities because the domain and operational economics justify it—not simply because code looks similar.