Save First, Sync Later: The Right Order for a Booking or Checkout Flow

A booking or a checkout looks like one action to the customer. They pick a slot, or fill a cart, tap confirm, and see a success screen. Behind that single tap, though, several separate things have to happen: a record has to be saved, a card may have to be charged, a calendar has to be updated, a confirmation email has to go out, and your team probably needs a notification. Each of those talks to a different system, and each of them can fail on its own. The question that decides whether your business loses money is not whether one of them will fail. It is what order you do them in, because the order decides what survives when one does.

This is a focused piece on that one decision: the order of operations. It sits underneath the larger question of building a booking system that behaves correctly under pressure, which we cover in the booking system that cannot double-book. If you want the full picture of reliable bookings, start there. If you want to understand the single most common way a booking gets thrown away, stay here.

The broken pattern: every step depends on the last

Here is how a lot of booking and checkout code gets written, especially when it is put together quickly. The steps run in a straight line, and each one is treated as a gate the next one has to pass through. Save the booking, then add it to the Google Calendar, then send the confirmation email, then notify the team. It reads cleanly, and on a good day it works perfectly. The problem is what happens on a bad day.

Imagine the email step fails. Maybe the email provider is having a slow minute, maybe a rate limit was hit, maybe the customer typed their address wrong. In the straight-line version, that failure often takes the whole operation down with it. The code throws an error, the request unwinds, the customer sees "something went wrong," and depending on how it was built, the booking that was already saved gets rolled back too. The customer made a booking. Your system had it. Then it threw it away because a completely separate email server hiccuped. Nobody would design that on purpose, but it is what "every step depends on the last" produces.

The principle: commit the source of truth first

The fix is to be clear about which one thing must survive no matter what, and to make that thing happen first and on its own. In a booking, that is the booking record. In a checkout, it is the paid order. That record is your source of truth: it is the thing you can rebuild everything else from, the thing your business would go to court over, the thing the customer believes exists the moment they see the success screen. Everything else, the calendar entry, the email, the Slack or WhatsApp ping to your team, is a copy or a courtesy. Useful, expected, but recoverable.

So the order becomes: do the one thing that has to be true, confirm it is really saved, and only then attempt the rest. And critically, the rest is attempted in a way that cannot undo the first step. If the calendar sync fails, the booking still stands. If the email fails, the booking still stands. Those later steps are best-effort. They are allowed to fail, because you have arranged things so that their failure costs you a retry, not a sale.

1. Commit the source of truth. Save the booking, or record the paid order, in your database and confirm it actually landed. Nothing else runs until this is solid.
2. Return success to the customer. Once the record is safe, the customer can be told it worked, because from their point of view it did.
3. Fire the best-effort side effects. Update the calendar, send the confirmation email, notify your team. Each of these is allowed to fail on its own without touching the record from step one.
4. Retry what failed. A side effect that did not go through is put on a queue and tried again later, or flagged for a human, so it eventually catches up without the customer ever being involved.

A booking, step by step

Picture a tour operator in Guyana taking a booking for a Kaieteur day trip. A visitor picks a date, enters their details, and confirms. The right order is boring in the best way. First, the system checks the slot is genuinely free and writes the booking, holding that slot against anyone else grabbing it at the same moment (the double-booking problem, which is its own topic). That write is the source of truth. The instant it succeeds, the visitor sees a confirmed booking, because it is confirmed.

Only then does the system reach out to the softer systems. It pushes the trip to the operator's Google Calendar. It emails the visitor their confirmation and what to bring. It pings the operator on WhatsApp so a human knows to prepare. If Google Calendar is down for maintenance at that exact second, the booking is still real and the calendar entry gets added on the next retry. If the confirmation email bounces because the visitor fat-fingered their address, the booking is still real and your team can reach out through the phone number you also captured. The visitor never experiences any of this. They booked a tour, and they have a tour.

A simple checkout, step by step

E-commerce has the same shape with one extra twist: money. A customer fills a cart and pays. There is a real ordering question about payment itself, which we will not solve in full here, but the principle is the same. The moment the payment is confirmed and the order is recorded, that paired fact, paid and recorded, is your source of truth. That has to be rock solid, because it is the difference between a customer who paid and got nothing and a customer whose order you can fulfil.

Once the order is safely recorded as paid, the receipt email, the entry in your fulfilment dashboard, the low-stock alert to your buyer, and any accounting sync are all best-effort. A receipt email that fails to send does not mean the customer did not pay. You already have their money and their order. You resend the receipt, and nothing about the sale is at risk. The mistake we see is checkout code that sends the receipt inside the same do-or-die block as recording the payment, so an email outage can leave a customer charged with no order on file. The order of operations is what prevents that.

Why this is a business decision, not just a technical one

It is tempting to file this under developer detail, but the consequence lands squarely on the business. The straight-line version fails in the most expensive way possible: it loses bookings and orders that were already made, at the exact moment demand is high enough to strain an integration. The correctly ordered version fails in the cheapest way possible: a confirmation email arrives a few minutes late, or a staff notification has to be resent. Same underlying hiccup, wildly different cost, and the only thing that changed was the order.

It also changes what a failure feels like to you as the owner. In the broken pattern, an outage in a third-party service you do not control, an email provider, a calendar API, becomes your emergency, because it is deleting your sales in real time. In the correct pattern, that same outage is somebody else's problem that your system rides out. Your bookings and orders keep landing, and the deferred work catches up when the other service comes back. Building software this way is a large part of what separates a system you can trust with real money from one that works only on quiet days.