How to Structure Functional Teams and Governance in Microservice Architecture

Functional Team Division in Microservice Architecture

Traditional monolithic architecture splits the system into layers (UI, backend logic, ORM, DBA, etc.) and organizes large teams accordingly. Changes to a component require cross‑team communication at every stage, leading to high maintenance cost and risk.

According to Conway's law, communication structures should mirror architecture; therefore, in microservice architecture, functional team division is a core consideration.

In microservices, each business capability is a service owned by an independent functional team that includes UI designers, backend developers, DBAs, operations, and maintenance staff. The team is responsible for the entire lifecycle of its service, promoting “you build it, you run it”.

When a change is needed within a service, communication stays within the team, eliminating cross‑team coordination. Only interface changes between services require inter‑team discussion, which can be minimized with well‑defined contracts.

Decentralized Governance of Microservices

Using a centralized API gateway may simplify entry points but can become a performance bottleneck as traffic grows, illustrating a microservice anti‑pattern.

Microservices favor decentralized governance: different services can be implemented in different languages (e.g., C++ and Java) and share common tools such as Thrift IDL for language‑agnostic interface definitions.

In a payment platform, Dubbo was used for SOA; when Dubbo failed, the system fell back to point‑to‑point Hessian calls, demonstrating service degradation without a central manager.

Interaction Patterns of Microservices

Common design patterns define contracts between producers and consumers.

1. Tolerant Reader – Consumers should be tolerant of changes in provider responses, filtering out unknown fields and using loose validation to avoid failures when new data appears.

Example: parameters may use enum values, but return DTOs should avoid enums and use strings to maintain compatibility.

2. Consumer‑Driven Contract – Contracts include provider contract, consumer contract, and consumer‑driven contract, ensuring providers do not break expectations set by consumers.

In a payment system, the accounting service provides a Dubbo interface; the transaction service only needs a subset of the returned fields, and the accounting service must honor idempotency and deduplication requirements imposed by the transaction service.

3. No‑Shared‑Data Pattern – Services should not share databases or caches; all interaction must go through well‑defined interfaces (RESTful APIs or RPC).

Decomposition and Composition Patterns of Microservices

Service decomposition follows domain verbs and nouns (e.g., order, product, inventory). Composition patterns include:

1. Service Proxy – A simple façade that forwards calls to a backend service, often used during system migration with read‑switch logic.

2. Service Aggregation – Orchestrates multiple services in a defined order, combining their results; exemplified by an e‑commerce front‑end aggregating product, cart, order, and payment services.

3. Service Chaining – A workflow where services call each other synchronously; suitable for short chains but can cause thread blocking.

In the e‑commerce example, the UI calls the transaction service, which chains to the inventory service for stock locking and deduction, illustrating the service chaining pattern.