Half one of two
Engines
How to design the piece of a system that runs when nobody is watching. Written from having built them and operated them, at the level of pattern rather than implementation.
Every page here answers the question in its first forty words, then shows the reasoning. Nothing on these pages describes any client's internals. A drawing of how a reconciliation loop works in principle is craft. A drawing of a specific one is a map, and maps do not go on the internet.
A scheduler is not a trigger. Cron fires and forgets, which is fine until the process dies mid run, or the same job fires twice, or somebody asks what happened at four in the morning and nothing can answer.
Every system eventually grows an action nobody should be able to take alone. Refunding money, releasing results, deleting a customer, messaging forty thousand people at once. The usual answer is a permission, and a permission is the wrong tool.
Every payment integration works in testing. The interesting question is what happens when the provider retries because your acknowledgement was slow, and the customer is credited twice for one payment.
Notifications look like the easiest thing in a product and become one of the hardest, because they cost money per message, they fail silently, and the person who needed one has no way to tell you it never arrived.
Somebody asks for a threshold to be configurable. Then a second condition. Then an exception for one group. Six months later you have built a programming language with no debugger, no tests and no error messages.
The other half of the job is the screen people use the engine through. Interface work .