Microservice Design Patterns: Database, Observability, and Cross‑Cutting Concerns

The article aims to help readers understand microservice architecture design patterns to overcome challenges inherent in microservice systems, dividing the discussion into two parts: the first covering decomposition and integration patterns, and the second covering database, observability, and cross‑cutting concern patterns.

It begins by listing core microservice principles such as scalability, availability, resilience, autonomy, decentralized governance, fault isolation, automated provisioning, and continuous delivery via DevOps, then notes the challenges these principles introduce.

Database Pattern

a. One Database per Service – Each microservice should have a private database accessed only through its API, using private tables, schemas, or dedicated database instances to enforce isolation.

Problem : Maintaining loose coupling, handling cross‑service transactions, querying data across services, scaling databases, and meeting diverse storage needs.

Solution : Provide each service with its own private database, possibly using private tables, schemas, or separate database servers, ensuring independent access and preventing other services from directly accessing its data.

b. Shared Database among Services – While not ideal for greenfield projects, sharing a database can be a pragmatic starting point for brownfield migrations, limiting the number of services per database to 2‑3 to preserve scalability and autonomy.

Problem : In monolithic applications being broken into microservices, denormalization is difficult and a suitable architecture is needed.

Solution : Allow multiple services to share a database as an initial step, treating it as a logical partition while planning eventual separation.

c. Command‑Query Responsibility Segregation (CQRS)

Problem : Queries that require data from multiple services become impossible when each service owns its own database.

Solution : Split the application into command and query sides; the command side handles writes, while the query side uses materialized views updated via event sourcing to serve read requests.

d. Saga Pattern

Problem : Ensuring data consistency across services for distributed transactions, such as enforcing credit limits across separate order and customer databases.

Solution : Implement long‑running business processes composed of sub‑requests, each with a compensating action on failure, using either orchestration (central coordinator) or choreography (event‑driven).

Observability Pattern

a. Log Aggregation

Problem : Understanding request flow across multiple service instances when each generates its own log file.

Solution : Deploy a centralized logging service (e.g., Loggregator, AWS CloudWatch) to collect, search, and alert on logs.

b. Metrics Collection

Problem : Monitoring performance and detecting issues in a highly composable microservice environment.

Solution : Use a metrics service that aggregates per‑operation statistics, supporting push models (New Relic, AppDynamics) or pull models (Prometheus).

c. Distributed Tracing

Problem : Tracing end‑to‑end requests that span multiple services.

Solution : Assign a unique request ID, propagate it across services, and record timestamps in a tracing system (e.g., Spring Cloud Sleuth, Zipkin).

d. Health Checks

Problem : Preventing traffic from being routed to unhealthy service instances.

Solution : Expose a health endpoint (e.g., /health) that verifies host status, dependencies, and custom logic; Spring Boot Actuator provides such an endpoint.

Cross‑Cutting Concern Pattern

a. External Configuration

Problem : Managing environment‑specific URLs and properties without rebuilding services.

Solution : Externalize all configuration and load it at runtime; Spring Cloud Config Server can store properties in Git and refresh them without restarts.

b. Service Discovery

Problem : Dynamically locating service instances whose IPs change due to container orchestration.

Solution : Deploy a service registry where instances register on startup and deregister on shutdown; clients query the registry to discover locations (e.g., Netflix Eureka, AWS ALB).

c. Circuit Breaker

Problem : Preventing cascading failures when downstream services become unavailable.

Solution : Use a proxy that implements circuit‑breaker logic, opening the circuit after a failure threshold and allowing limited test requests; Netflix Hystrix is a common implementation.

d. Blue‑Green Deployment

Problem : Reducing or eliminating downtime during deployments and rollbacks.

Solution : Run two identical production environments (blue and green) and switch traffic between them; most cloud platforms support this strategy.

In summary, the article presented database, observability, and cross‑cutting concern patterns for microservices, offering practical solutions to common architectural challenges.