Principle Statement Format

"Prefer eventual consistency" is not a principle. It is a preference with no rationale, no implication and nothing checkable, so the first engineer with a good reason overrides it — correctly.

A principle needs four parts: the statement, the rationale, the implications for design, and the exception process. Without the rationale it cannot be applied to a case its author did not anticipate. Without the implications it changes no design. Without an exception process it will be violated silently rather than deliberately.

Why it matters

Principles are how an organisation makes consistent decisions without routing every decision through one person. A principle that has never caused anyone to change a design is documentation rather than governance, and the honest response is to delete it.

Implementation patterns

• Write the four parts explicitly. For a quick-commerce platform: statement — stock is strongly consistent within a dark store at the moment of reservation and eventually consistent everywhere else; rationale — overselling in a store causes a physical failure that cannot be compensated cheaply, while a stale city-wide count causes a slightly wrong browse experience; implication — the reservation write and the store's stock ledger share one transactional boundary, and catalogue, search and recommendations read projections that may lag; exception — none for reservation, and any proposal goes to the design authority.
• Test each principle by asking what it rules out that somebody actually wanted. If nothing, it is not doing work.
• Keep the list short. Five to eight principles are memorable; thirty are a reference document nobody consults.
• Attach an owner and a review date, because principles derived from a business model outlive the business model.
• Log the exceptions. An exception register tells you whether the principle is right; a principle with forty exceptions is describing the wrong rule.

Industry example

The consistency principle above is the one that determines almost everything structural in a ten-minute delivery product: which write is transactional, what the checkout path is allowed to call, what may be cached, and what a stale read is permitted to show. It is a genuine principle precisely because it forbids something attractive — putting the reservation behind the same eventually-consistent projection as everything else, which would be simpler and faster.

Failure scenarios

• Principles as slogans — "cloud first", "API first", "buy before build" — that are unfalsifiable and therefore inert.
• No exception process, so violations happen quietly and the principle's real coverage is unknown.
• Too many principles, which is equivalent to none because nobody can recall them at the moment of decision.
• Principles that outlived their rationale, still enforced by a governance body that no longer remembers why.

Trade-offs

Strong principles reduce the design space, which is their purpose and also their cost: they will occasionally forbid a locally optimal choice. That is acceptable when consistency across many teams is worth more than local optimisation, and unacceptable when it is not.

The mitigation is the exception process. A principle with a fast, recorded exception route is stronger than one without, because it gets followed in the ordinary case and challenged openly in the unusual one, rather than being ignored in both.

Interview question

"Show me a principle from your organisation. What did it stop someone doing in the last six months, and what would have happened if it had not existed?"