Since lesson M3.3, the Windows program and the new layer have worked with one database, and since lesson M3.4 it has lived in
Azure SQL. That is the simplest form of dual running: There is nothing to synchronize, because there is only one set of data. The
table in docs/data-contract.md says who may write what, and the role OrderBookNew enforces it.
This lesson asks what happens when that state is not enough: A piece of data is to move into a database of its own, and for a few weeks two copies exist that somebody has to keep identical. Then a single sentence decides between success and trouble: For every piece of data there is exactly one owner at any time. Everything else in the lesson is the implementation of this sentence. The patterns behind it, that is, events, messages and consistency between systems, are covered by K4, module 4.6; here the subject is the transition in the Order Book.
First the question: Do you need two databases at all?
Every second database is a burden that you carry until switch-off. So ask the question before any technique:
| Share one database (the state after lesson M3.3) | Copy data into a database of its own | |
|---|---|---|
| Effort | low: roles, views, protective layer | high: synchronization, reconciliation, ownership change |
| Consistency | one truth, transactions work | two truths, one of them lags behind |
| Own rules of the new system | only as far as the old program tolerates them | freely selectable, but enforceable only after the ownership change (see below) |
| Way back | flip the switch | as long as the synchronization runs: give ownership back |
| When it makes sense | almost always, until the old program is switched off | when the new system has to run independently of the old database or can no longer bear its structure |
Microsoft's documentation on the strangler fig pattern describes both states. First the new system reads and writes the shared database; only later does it get a database of its own for its area, filled by synchronization, and in the end that one is the authoritative source. The Order Book stays in the first state as long as possible. As an example of the second we take the customer master data: The new system wants to manage customers with rules of its own, for example with contact persons, and to have a database that is no longer tied to the tables of the old program.