Hints for Microservice Design: Business Architecture, Metrics, and Autonomy

Author Bio: Yao Gangqiang has extensive experience in technical and business architecture; from 2013‑2019 he worked at Zhihu, witnessing its growth to tens of millions of DAU, and since 2019 he has been chief architect of the Zebra division at Yuanfudao, focusing on engineering practice improvement, architecture optimization, and metrics‑driven DevOps culture.

This talk is a condensed version of the 2021 GIAC presentation "Hints for Microservice Design".

Preface

The talk discusses business architecture rather than technical architecture, emphasizing that business architecture lacks clear benchmark criteria. The content is presented as "hints" rather than strict guides, and the author invites skepticism.

The presentation is divided into two parts: (1) posing problems, and (2) how to measure whether the problems are solved and possible solutions.

It focuses on "expected problems, goals, current state" and "how to design architecture, dimensions, and good standards".

Expected Problems, Goals, Current State

Instead of starting with a definition of microservices, the discussion begins with the problems we expect microservices to solve.

What Should Microservices Solve?

The author evaluates R&D team performance using four key metrics: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. These metrics measure both speed and quality.

Good architecture should enable autonomy, minimal inter‑dependency, and allow teams to work independently.

Current State

Most businesses face sub‑optimal microservice splits, leading to coupling problems.

Goal

The ideal system resembles LEGO: each subsystem (business capability) is a component that can be combined to form complex capabilities while remaining autonomous.

Case Studies

Initial simple system with a single module.

Supply‑chain split due to critical failures.

Lesson‑module split as a shared component.

Summarized rules from the splitting experience.

Final complex system after applying the rules.

New problems still appear, prompting the next discussion on measuring autonomy.

How to Design Architecture: Dimensions and Good Standards

Design Dimensions

The classic "4+1" view model is referenced, but the talk focuses on two dimensions: Logical view (business modules) and Process view (runtime processes).

Logical view maps to Process view through deployment.

Logical View (Business Architecture)

Common modeling methods and principles are discussed, but the author stresses that they are often too vague. Good standards include stable interfaces, minimal shared mutable data, and high ratio of interface stability to implementation changes.

Layered architecture (DAO, Service, Application, View) is presented as a practical decomposition.

Examples from Zhihu and other systems illustrate good and bad layering.

Key criteria for good business architecture: no impact between modules, sharing only immutable data, stable interfaces, and low interface‑change frequency.

Process View (Runtime Architecture)

Physical isolation aims to achieve runtime autonomy. Benefits and drawbacks (Fallacies of Distributed Computing, Law of Demeter) are discussed.

Solution: compile modules with different autonomy requirements into separate deployable packages and run them in distinct process groups, ensuring coordinated deployment and rollback.

The author emphasizes that business architecture and runtime architecture are not one‑to‑one; design the business model first, then the physical deployment.

Summary

The talk first identified problems, current state, and goals, then derived standards for good business architecture and provided hints for achieving both logical and physical autonomy. The two most important hints are highlighted in the final slides.

Postscript

Areas for improvement: too many points dilute focus, unclear sectioning, and overly generic examples.

Too many topics make the key message fuzzy.

Section division needs clearer logic.

Excessive generic phenomena reduce depth; focusing on one or two concrete cases would be better.

The main ideas are credited to Tao Wen and Udi Dahan.

Feedback is welcomed via comments or private messages; the author offers private WeChat discussions for valuable insights.

References

Business Logic Splitting Model

Udi Dahan

Complexity Has to Live Somewhere

Monolith First

Don’t start with a monolith

Do we need microservices or business capabilities?

Only "many micro" counts as microservices

Modular Monolith

On the Criteria To Be Used in Decomposing Systems into Modules

Hints for Computer System Design

Technical original articles are welcome for submission via the public account menu.

High‑Availability Architecture

Changing the Way the Internet Is Built