In a system of more than one component, the fastest way to create a defect nobody can reproduce is to let two components write the same fact. Ownership is the rule that prevents it: for each piece of data, exactly one component holds the authority to create and change it, and every other component either reads a copy or asks the owner to make the change. Because the owner is the only writer, the rules about that data, its validation, its history and its corrections all have one home. Copies are allowed and often necessary, but a copy must be marked as a copy, and the design must state how out of date it is allowed to be. The test is a question you can ask about any field in any design: who is allowed to change this? If the honest answer names two components, you have two sources of truth, and you will eventually have two different answers with no way to tell which is right. Ownership also predicts the shape of your integrations, because a component that needs data it does not own needs either a read path to the owner or a subscription to the owner's changes. You will be able to take the data list from a brief, assign each item a single owning component, rewrite every other component's access to it as a read or a request, and state how stale each copy may be.
The Saga pattern addresses data consistency across microservices by decomposing a single cross-service transaction into a sequence of local steps, each performed by an independent service, with prede…