Skip to content
- To maintain independent deployability, code sharing between microservices should be minimized.
- For example, shared data access layers (like a DynamoDB abstraction) may seem beneficial but can cause issues as services evolve independently.
- Deciding ownership and maintenance of shared libraries can become problematic as requirements diverge.
- Cross-cutting concerns, such as logging and observability, are ideal candidates for shared implementations across services.
- Shared structured logging enables efficient querying and uniformity across microservices.
- Publishing events with a consistent schema also benefits from shared libraries.
- For these scenarios, the “don’t repeat yourself” mantra is appropriate.
- Avoid leaking domain or business logic outside service boundaries when sharing code.
- Updates to shared libraries should not be mandatory or forced on teams; publish new versions and let teams upgrade when ready.
- Avoid breaking changes and track usage through telemetry to manage and monitor adoption.
- Providing client libraries (similar to AWS SDKs) to streamline internal usage of services is recommended.
- These libraries should wrap APIs, handling concerns like authentication and endpoints, without including business logic.
- The goal is to ease integration without compromising service boundaries or leaking core logic.
- Only share code for genuine cross-cutting concerns and avoid sharing domain-specific logic.
- Implement shared libraries as wrappers, ensuring no business logic leaks into common code.
- Communicate version updates clearly and allow flexible adoption timelines.
- Use telemetry to track which services are using shared libraries and monitor for outdated versions.