Implementation Patterns and Operational Concerns in Microservices

Key Insight

Communication within microservices involves fundamental decisions between synchronous and asynchronous styles, typically employing protocol-aware heterogeneous interoperability. 'Protocol-aware' signifies that services must understand and potentially discover the communication protocols (e.g., REST, message queues) used to interact with others, without a central integration hub. 'Heterogeneous' highlights the support for polyglot environments, allowing different services to utilize diverse technology stacks, which can actively prevent accidental coupling by forcing distinct interfaces (e.g., one team using Java and another using .NET). 'Interoperability' describes the common need for services to call one another over the network for collaboration, even while discouraging transactional calls across service boundaries. Asynchronous communication often leverages events and messages, manifesting an internal event-driven architecture.

While microservices prioritize decoupling for domain logic, operational concerns like monitoring, logging, and circuit breakers benefit from commonality. The 'sidecar pattern' addresses this by encapsulating shared operational components alongside each service, allowing a shared infrastructure team to manage and upgrade them without impacting individual service teams. These sidecars connect to form a 'service mesh', providing a unified control plane and holistic operational view across all microservices for concerns like monitoring levels and logging. Service discovery is often integrated into the service mesh and API layer to build elasticity, monitoring requests and spinning up new service instances for scale. For user interfaces, options include a 'monolithic frontend' interacting with the API layer, or 'microfrontends' where each service emits its UI components, creating synchronous granularity and isolation from UI to backend.

Coordinating complex workflows in microservices can be achieved through 'choreography' or 'orchestration'. Choreography, aligned with the bounded context philosophy, involves services calling each other as needed without a central coordinator (e.g., a CustomerWishList service calling CustomerDemographics). While preserving decoupling, it can complicate error handling. Alternatively, 'orchestration' introduces a localized mediator service solely responsible for coordinating calls across several services, centralizing complexity but creating coupling. For transactional coordination across services, the general advice is to avoid it and fix granularity issues instead, as it violates decoupling. If unavoidable, the 'saga pattern' is used, where a mediator coordinates a transaction across multiple services, recording success or failure and, in error conditions, sending compensating transactions to undo successful prior operations. This pattern, however, introduces significant complexity and coordination traffic and should be used sparingly.