How to Structure Functional Teams and Service Patterns for Scalable Microservices

Functional Team Division in Microservice Architecture

Traditional monolithic systems split responsibilities into layers, and project management often creates functional teams such as UI, backend logic, ORM/DBA, etc. Each team owns its layer and guarantees component quality. Any component upgrade requires cross‑team communication across requirement, design, development, testing, and deployment stages, leading to high maintenance cost and risk.

According to Conway's law, communication structures should mirror architectural structures, so in microservice architecture the way functional teams are divided becomes a core consideration.

Decentralized Governance of Microservices

The author recounts an experience where a unified API gateway became a performance bottleneck as traffic grew, illustrating a microservice anti‑pattern. Microservices advocate decentralized governance: different services can be implemented in different languages (e.g., C++ and Java) and share tools such as Thrift IDL to define language‑agnostic interfaces.

In a payment platform, the first layer uses Dubbo; if Dubbo fails, the system falls back to point‑to‑point Hessian calls, demonstrating service degradation without a central manager.

Interaction Patterns of Microservices

Microservice interaction design defines contracts that both producers and consumers must obey.

1. Tolerant Reader Pattern – Consumers must be tolerant to changes in provider responses, filtering out unknown or optional fields and using permissive validation so that only completely unrecognizable messages trigger exceptions. An enumeration usage rule is given: enums may appear in request parameters but should be avoided in response DTOs to prevent deserialization errors.

2. Consumer‑Driven Contract Pattern – Contracts are categorized as provider contracts, consumer contracts, and consumer‑driven contracts. Provider contracts define what a service offers; consumer contracts specify the exact data a consumer needs; consumer‑driven contracts bind the provider to never break the consumer’s expectations.

Provider contract: the service defines functions and message formats unconditionally.

Consumer contract: precise description of a consumer’s data needs, can identify existing provider contracts or discover missing ones.

Consumer‑driven contract: the provider commits to honor all consumer expectations.

An example from a payment platform shows a transaction service invoking an accounting service, where the provider contract includes parameters (account ID, order ID, amount) and the consumer contract only uses order ID and status, while the consumer‑driven contract enforces idempotency and duplicate filtering.

3. No‑Data‑Sharing Pattern – Unlike SOA's ESB bus, microservices should not share databases or caches for inter‑service communication. Using shared storage creates hidden data contracts and complicates deployment and scaling.

Decomposition and Composition Patterns

Service decomposition follows business functions (e.g., order, product, inventory, cart, payment, logistics). After fine‑grained services are built, they can be combined using several patterns:

1. Service Proxy Pattern – A simple composition where a proxy forwards calls to a backend service, possibly transforming the response.

Typical use: smooth system migration with phases (dual write, migrate history, switch reads, drop dual write).

2. Service Aggregation Pattern – Calls multiple dependent services in a defined order, aggregates and transforms their data, and returns a combined result. Each service may have its own storage; the aggregator may also store data.

Benefits: DRY principle, independent development, clear project structure, reusable sub‑services.

3. Service Chaining Pattern – A workflow where Service 1 calls Service 2, which calls Service 3, etc., with synchronous RESTful calls. Not recommended for deep chains; prefer aggregation when possible.

4. Service Branch Pattern – Combines proxy, aggregation, and chaining. A branch service may have its own database and invoke multiple backends, then compose results.

Complex dependency trees often appear in real platforms; the payment service example shows a branch service handling multiple external payment gateways and internal balance payments.

When a foundational service with 8 instances loses one instance, the impact on traffic can be greater than 1/8 because multiple service layers may call the same foundational service, causing cumulative loss.

Mathematical formulas (shown as images) illustrate how to calculate required instance counts to keep availability fluctuation below a target threshold.

5. Asynchronous Message Pattern – Synchronous REST calls can block threads and cause cascade failures. Core services use synchronous calls; peripheral services communicate via asynchronous message queues.

Typical case: after a transaction completes, a message is sent to the logistics system to trigger shipping.

Microservice Fault‑Tolerance Patterns

1. Bulkhead Isolation – Separate service containers (e.g., pre‑production, gray, production) and thread pools per functional area to prevent a failure in one area from exhausting resources of others.

2. Circuit Breaker – Stops calls to an overloaded or failing service, similar to a household fuse, protecting the whole system.

3. Rate Limiting – Controls request concurrency using counters, token buckets, or semaphores.

Counter example: a ring buffer records requests per second; when the threshold is exceeded, further requests are rejected.

Token bucket example: a producer thread generates tokens at a fixed rate; each request must acquire a token.

Semaphore example (Java): only a limited number of concurrent requests are allowed.

public class SemaphoreExample {
    private ExecutorService exec = Executors.newCachedThreadPool();
    public static void main(String[] args) {
        final Semaphore sem = new Semaphore(5);
        for (int index = 0; index < 20; index++) {
            Runnable run = new Runnable() {
                public void run() {
                    try {
                        // acquire permit
                        sem.acquire();
                        // only 5 requests can be here simultaneously
                        Thread.sleep((long) (Math.random()));
                        // release permit
                        sem.release();
                        System.out.println("Remaining permits: " + sem.availablePermits());
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            };
            exec.execute(run);
        }
        exec.shutdown();
    }
}

4. Fallback (Fail‑over) Mode – Handles rejected requests by fast‑failure, switching to backup services, or retrying with idempotent operations.

Granularity of Microservices

Services should be split by business function until each service has a single responsibility and can be independently deployed and scaled. Over‑splitting leads to excessive service count and coordination overhead; under‑splitting creates tightly coupled, coarse‑grained services that hinder agility. The recommended approach is to split just enough to allow consumers to freely compose underlying services while keeping team size manageable.

Source: https://blog.csdn.net/qiansg123/article/details/80131044