Consistency Profile is a contract that sets consistency requirements per domain, key, and scene, instead of one label for the whole system. Each profile states which consistency model applies, the staleness budget, the tail latency target, retry limits, and compensation rules. The term was introduced by Dongsun Moon in Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow (2026).
“We are CP” or “we are AP” tells teams nothing.
Beyond Microservices, Chapter 4
Definition
A Consistency Profile is written for a coordinate, not for a system. The coordinate has three parts.
- Domain: the part of the business the data belongs to, such as messages or user profiles.
- Key: the unit whose order and freshness matter, such as one conversation or one user.
- Scene: the moment a person experiences, such as the sender looking at the message they just sent, or someone searching last year’s history.
For each coordinate, the profile states the consistency model (linearizable, causal, read-your-writes, monotonic, or eventual), the staleness budget, the tail latency target, the retry and idempotency limits, and how the system compensates when something goes wrong. The same organization and the same stack carry different profiles, because different scenes carry different responsibilities.
Why one label is not enough
Stronger consistency costs latency even when nothing is failing, and users experience tail latency, not the average. A system that is “strongly consistent” everywhere pays that cost in scenes that do not need it. A system that is “eventually consistent” everywhere breaks the scenes that do, such as a sender who cannot see the message they just sent. The datastore is a tool. The profile is what you are actually buying, and it can differ for every scene a single store serves.
A profile is also how an architecture choice becomes testable. “Eventually consistent” cannot fail a test. “The unread count for a chat is at most five seconds stale at P95” can.
How to use it
- List the scenes that matter to users, not the services. Start with the ones where a stale or reordered answer would be noticed.
- For each scene, write the profile as plain sentences: the key, the consistency model, the staleness budget, the tail latency target, and the retry and compensation rules.
- Measure what each sentence promises. For a staleness budget, track the age of the oldest change not yet applied, at P95.
- Move the sentences into policy that a pipeline checks, and tie each profile to its service level objective and error budget, so that a violated profile changes what the team does next.
How it gets misused
A profile that lives only in a document is a label with more words. Copying values from another team’s profile repeats the error the profile exists to prevent, because the values come from the scene. And a staleness budget that nobody measures is a wish: the first time anyone learns it was exceeded is when a user notices.
How to cite
First published in 2026 in Beyond Microservices.
Moon, D. (2026). Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow. Beyond Moon Press. ISBN 9781067722302. Consistency Profile is defined in Chapter 4.
@book{moon2026microservices, author = {Moon, Dongsun}, title = {Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow}, publisher = {Beyond Moon Press}, year = {2026}, isbn = {9781067722302}, url = {https://dongsunmoon.com/consistency-profile/}, note = {Introduces the Consistency Profile (Chapter 4)}}