Event-driven systems without the buzzwords: building business software that does not lose orders

The first version of this article was about Kafka clusters and planetary scale. That is the right tool for a few companies. For almost every business I work with, the real problem is smaller and more important: making sure a paid order, a booking or a customer message is never lost or counted twice.

The words, in plain English

• Event: something that happened. "Payment received." "Booking cancelled."
• Webhook: another company's system telling yours about an event, by calling a web address you give it.
• Queue: a list of jobs waiting to be done, so slow work happens in the background.
• Microservices: splitting one application into many small ones that talk to each other. Useful for large teams, costly for small ones.

Martin Fowler, one of the best-known writers on software architecture, recommends starting with a single application and splitting it only when you have a clear reason. I agree. A well-organised single application is cheaper to build, easier to change and easier to secure.

Habit 1: confirm with the source

When a customer pays by card, the payment page sends them back to your site. It is tempting to mark the order paid at that moment. Do not. A returning browser can be faked, refreshed or closed halfway.

In iVishwa's client portal, when a card payment comes back from our payment provider, the server asks the provider directly whether the payment really succeeded, and only then marks the invoice paid and issues a receipt. Messages that arrive from WhatsApp are accepted only when they carry Meta's valid signature.

Habit 2: make every step safe to run twice

Webhooks are delivered "at least once", which means sometimes more than once. Stripe, for example, keeps retrying a webhook it could not deliver for up to three days. If your code adds a booking every time the same notification arrives, a network hiccup becomes a double booking.

The fix is simple to describe: each event carries an ID, and your system checks whether it has already handled that ID before doing anything. Engineers call this idempotency. Ask any developer you hire how they handle it.

Habit 3: record what happened

When a customer says "I paid, but my booking is not there", you need an answer in minutes, not a guess. Keep a log of every important event: what arrived, when, and what your system did with it. Our admin keeps an activity record of every approval, payment and sign-in for exactly this reason.

Slow work belongs in the background

Sending an email, a WhatsApp alert or a PDF receipt should never keep a customer staring at a spinner. The order is saved first, the customer sees "done", and the notifications go out in the background, with retries if a service is down.

When you really do need more

Dedicated event platforms and event sourcing earn their complexity when volumes are very high, when many teams work on one system, or when a complete history of every change is a legal requirement. If that is you, it is a big project and worth doing properly. If it is not, a single well-built application with the three habits above will serve you for years.

Questions to ask your developer

1. How do you confirm a payment before marking an order paid?
2. What happens if the same webhook arrives twice?
3. What happens if the email or SMS service is down?
4. Where can I see what happened to a specific order?

Written by Vish Jay

I design and build websites, online stores and business systems for clients in the US, UK, Europe, Australia and Canada, from Colombo, Sri Lanka. When you work with iVishwa, you talk to me directly, from the first call to launch and after.