Key Practices and Considerations in Microservice Architecture Design

This article discusses practical experiences and reflections on microservice architecture design, building on previous SOA and microservice articles.

Core of Microservice Architecture

The core idea is to split a traditional monolith into small, independent microservices that communicate via lightweight APIs. Splitting involves multiple dimensions: team division, code‑level modularization with independent build and packaging, and database partitioning.

Database Splitting by Sub‑Domain

In practice, a monolithic system may be broken into dozens of microservices, but creating a separate database for each leads to high integration complexity and distributed transaction issues. Instead, databases are split by business sub‑domains, allowing multiple services to share a database while still achieving code‑level decoupling.

Microservice and Microservice API Interfaces

Microservice modules and the APIs they expose are distinct concepts. Registration frameworks like Spring Cloud register whole services, not individual APIs. Effective architecture requires controlling interactions at the coarse‑grained API level rather than allowing unrestricted service‑wide calls.

Designing for API‑First

Before implementation, define microservice boundaries and their API contracts. Parallel development can proceed once contracts are agreed, reducing integration problems later. API‑first design also emphasizes governance of interface definitions.

Building Independent Domain‑Composite Microservices

Domain‑composite services orchestrate multiple microservice APIs, handling distributed transactions and business rules without owning their own database. This aligns with DDD’s application layer, while underlying domain services provide coarse‑grained APIs.

Microservice Gateway and API Gateway

Microservice gateways integrate with service registries for discovery, load balancing, and routing, while API gateways control access at the API granularity. Teams may run their own gateways, but cross‑team API coordination should be handled by a platform‑level API gateway.

Common Base JAR Dependencies

Microservices share common SDK/JAR components that are versioned independently. Only services that depend on an updated component need to be rebuilt, minimizing unnecessary compilation and deployment while allowing multiple JAR versions to coexist.

Designing for Decoupling

Use caching for query‑side decoupling and message middleware for command‑side (CUD) operations, following CQRS principles. This reduces tight coupling between services and improves scalability and resilience.

Change Impact Analysis

Because HTTP API changes may not cause compile‑time errors, it is essential to map interface interactions in a matrix to understand which services are affected by a change. Automated unit and integration tests based on this matrix help catch issues early.