Decision Sunset is an expiration date attached to an architectural decision, standard, or policy. When the date arrives, the decision is re-evaluated against the evidence gathered since it was made, instead of being renewed automatically. The practice was introduced by Dongsun Moon in Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow (2026).
Decision Sunsets prevent yesterday’s reasonable choice from becoming tomorrow’s unexamined constraint.
Beyond Microservices, Glossary
Definition
A Decision Sunset is a date written into the record of a decision at the moment the decision is made. Until that date the decision stands. On that date it does not quietly continue. Someone has to review it with the evidence that has accumulated, and choose one of three outcomes.
- Renew, only with fresh evidence that the decision still holds, and with a new sunset.
- Revise, by making a new decision with its own record and its own sunset.
- Retire, which is the default for exceptions such as “a shared database view is allowed for three months”. An exception that nobody renews with evidence ends.
The review is a Post-Decision Review. It sets the decision’s original assumptions against what happened, using the measures the decision was supposed to move, for example tail latency, change failure rate, time to restore, and the Release Coupling Ratio.
Why decisions need an expiry
An architecture decision record preserves why a choice was made. It does not tell anyone whether the choice is still right. Records accumulate, the assumptions behind them drift, and the system keeps obeying decisions that nobody would make today. Systems in sustained use grow in complexity (Lehman’s laws), and every observable behavior eventually acquires dependents (Hyrum’s law). Without a forcing date, the cheapest course is always to leave an old decision alone, and planning optimism and the reluctance to abandon a commitment push the same way.
A record can be marked superseded when someone writes a newer decision. A sunset is different: it forces the review even when nobody thought to write one. In real-options terms, the sunset is the expiry date of the option to change your mind, set while changing it is still cheap.
How to use it
- Add four fields to your decision record template: the sunset date, the owner of the review, the assumptions the decision depends on, and the evidence that would change it.
- Set the date by risk. The examples in Beyond Microservices range from three months for a temporary exception to six to twelve months for a narrow exception to a standard, with quarterly review in between. Shorter is better for exceptions, longer for decisions that are expensive to reverse.
- Make the date enforceable. A check that fails when a record passes its sunset without a review, or a list of decisions expiring this quarter, does more than a calendar reminder.
- At the sunset, hold the Post-Decision Review, record the outcome, and if the decision is renewed or revised, set the next sunset.
How it gets misused
The common failure is the rubber stamp: every decision renewed at its sunset with no new evidence, which keeps the paperwork and loses the point. Sunsets that are too short turn reviews into noise, and sunsets with no owner simply pass. A sunset also cannot rescue a decision whose assumptions were never written down, because then there is nothing to check at the review.
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. Decision Sunset appears in Chapters 1, 7, and 16 and the Glossary.
@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/decision-sunset/}, note = {Introduces the Decision Sunset (Chapters 1, 7, 16)}}