The Pitfalls of Centralizing Key Services

Centralizing key entities like customer data might seem efficient, but it can lead to serious architectural problems.

Complexity and Overload Centralizing all data in one place makes the system complex and cumbersome. A single entity ends up handling scenarios for multiple domains, which makes any changes challenging and risks tightly coupling every service to this central point.

Brittleness More dependencies create brittleness. Any changes to a centralized service can lead to cascading failures across systems, requiring extensive testing and coordination.

The Missed Insight: Rate of Change While abstraction helps with flexibility, the true success of a system depends on its ability to handle frequent changes without disrupting other parts.

Centralizing services can lead to complexity and brittleness. Instead, architectures should prioritize flexibility, abstraction, and be designed to handle the rate of change effectively to maintain scalability and stability. After identifying that threat, as an architect, you could write an ADR (Architectural Decision Record).

Architectural Decision Record: Centralizing Key Services

Title: The Pitfalls of Centralizing Key Services

Context: We considered centralizing customer data to streamline access for multiple domains (insurance, finance, etc.), but this approach raised concerns about complexity and brittleness.

Decision: We decided against centralizing services like Customer Service, opting for a distributed model that aligns with domain boundaries to promote local autonomy and flexibility.

Reasons for Decision:

1. Complexity: Centralizing customer data creates an overloaded service, making it slow and difficult to manage.
2. Brittleness: Small changes in a centralized service can break multiple domains, increasing coordination and testing efforts.
3. Rate of Change: Centralized systems struggle to adapt quickly, causing delays in feature delivery.

Pros of Distributed Approach:

• Each domain has its own service, improving autonomy and adaptability.
• Abstraction and flexibility are prioritized, making the architecture more resilient.

Cons of Distributed Approach:

• Ensuring consistency across distributed services may require extra effort.
• Data duplication could occur but can be mitigated with synchronization strategies.

Consequences:

• We’ll adopt a distributed service model with clear interfaces for data exchange.
• Asynchronous communication and event-driven designs will minimize tight coupling.