Since module 2.5, anyone can book an appointment in the Kladde publicly. So far, the person who books learns about it only from the page that appears after submitting. From this lesson on, they get a confirmation, and from lesson 2.8.5 on, that is a mail with a link, without which the booking doesn't count.
That sounds like two lines: save the booking, send the mail. This lesson shows why those two lines are never reliable, and builds the pattern that makes it work: the outbox, the Kladde's out tray.
Saving and sending: two systems
The booking lands in SQL Server, the mail at a mail service. Those are two systems, and between two steps in two systems the process can end at any moment: with a new deployment, a crash, a restart of the machine. Play through both orders:
| Order | What can go wrong between the steps | Result |
|---|---|---|
| save first, then send | the process ends after saving | the booking exists, the mail never comes |
| save first, then send | the mail service is unreachable right now | the booking exists, the mail never comes, unless someone notices |
| send first, then save | saving fails (double booking, database gone) | a mail confirms a booking that doesn't exist |
A shared transaction around both doesn't help. A database can roll back its change, a mail service can't: a mail that has been sent has been sent. Distributed transactions across systems aren't offered by mail services or by most interfaces on the network in the first place.