If you have a handful of systems and each one needs data from one or two others, point-to-point integration is usually the right choice. It is simpler to build and easier to support. Event-driven integration earns its keep when several systems need to react to the same thing, when one system being slow or offline shouldn't stop the rest, or when each new connection is harder to add than the last one was.
What is the difference between point-to-point and event-driven integration?
What is point-to-point integration?
Point-to-point integration means each system calls the system it needs directly. An e-commerce platform calls the finance system's API to post an invoice, then calls the warehouse system's API to raise a pick request. The sender knows who it is talking to, what format they expect and what to do if the call fails.
What is event-driven integration?
Event-driven integration means a system publishes a message saying something has happened, such as "order placed", to a message broker or event stream. Any system that cares subscribes to that event and acts on it in its own time. In this model the e-commerce platform doesn't know finance or the warehouse exist. It just announces the order.
The real difference is where the knowledge sits. With point-to-point, the sender knows every receiver. With event-driven integration, the sender only knows the event, and each receiver decides what to do with it.
When is point-to-point integration enough?
Direct connections aren't a bad habit you're meant to grow out of. For plenty of organisations they are the sensible long-term choice. Direct calls tend to work well when:
- There are few connections. Three or four systems with a clear, stable flow between them, where the caller can cope if the other side is briefly down, rarely need anything more.
- The caller needs an answer straight away. A stock check at checkout or a credit check before accepting an order needs a reply within the same request. That is what a direct API call is for.
- Each piece of data has one consumer. If only finance ever needs the invoice, send it straight to finance.
- The systems rarely change. If nobody is replacing or extending the finance or warehouse system, direct coupling stays cheap.
- Your team has to support it. A direct call is easy to trace, with one request, one response and a log entry on each side.
Point-to-point integration still needs discipline. Put each connection behind a small, well-defined API. Handle retries and failures deliberately. Write down which system owns which data. Built like that, direct integration can stay healthy for years.
When should you use event-driven integration?
The case for events gets stronger as more systems care about the same business event. These are the signs we look for.
- One action triggers work in many places. A new order has to reach finance, the warehouse, the CRM, customer email and reporting. With direct calls, the e-commerce platform has to call all five and handle five sets of failures.
- New consumers keep turning up. Every new system that wants order data means changing the sender. With events, the new system subscribes and the sender is left alone.
- One slow or offline system holds everything up. If warehouse maintenance stops you taking orders, the systems are tied together too tightly. A durable message broker holds the message until the warehouse is back, within whatever retention and retry limits you configure.
- Load arrives in bursts. A sale or a month-end run can produce more than a downstream system can absorb in one go. With events, that system works through the backlog at its own pace.
- You want a reliable record of what happened. If the broker keeps a log of events rather than deleting them once read, you get a history of business events. That helps with troubleshooting and feeding reporting systems, and with the right retention and access controls it can support auditing too.
- You are replacing systems in stages. While a legacy system is being retired, the old and new versions can both listen to the same events for a while. That makes a gradual switch-over much safer.
What are the pros and cons of point-to-point and event-driven integration?
Neither approach comes free.
| Point-to-point | Event-driven | |
|---|---|---|
| Simplicity | Easy to understand and trace | More moving parts: a broker, topics, subscribers |
| Immediate answers | Natural fit | Not designed for request-and-reply |
| Adding a new consumer | Change the sender each time | Subscribe without touching the sender |
| Failure in one system | Can block the caller | Others carry on; messages wait |
| Data consistency | A successful call confirms one update, not a change across every system | Systems catch up asynchronously; how fast depends on backlog and failures (eventual consistency) |
| Monitoring | Per connection | Needs end-to-end tracing across consumers |
| Skills needed | Common API skills | Messaging design, idempotency, ordering, replay |
What does eventual consistency mean in practice?
Eventual consistency means systems receiving the same event won't all update at the same moment, but they will catch up. The finance system might record an order a few seconds after the warehouse does. For most business processes that's fine. For some, such as stopping a customer spending credit they no longer have, it isn't. Then you either keep that step as a direct call or design for the delay explicitly.
How much extra operational effort does event-driven integration add?
A message broker is one more piece of infrastructure to run, secure and monitor. Messages can arrive twice or out of order, and some may never be processed, so every consumer has to be written with that in mind. Without proper monitoring, a failed subscriber can go unnoticed until someone asks why the reports are wrong.
How do you tell which integration approach you need?
Ask these questions about each important business flow, not about your whole estate at once.
- How many systems need to know when this happens? One or two stable consumers point to direct calls. Several, each changing on its own timetable, point to events.
- Does the caller need an answer before it can carry on? If so, that step is a direct call, even inside a design that is otherwise event-driven.
- What happens today when one system is unavailable? If the honest answer is "everything stops", and that is a real problem for the business, events will help.
- How often do you add or replace systems? Frequent change favours events. A stable estate favours direct calls.
- How long can systems safely disagree? If a decision needs an authoritative answer immediately, keep that step synchronous.
- Who is going to support it? If nobody in your team has run messaging infrastructure before, allow for that, or use a managed service.
Warning signs your point-to-point integrations have outgrown themselves
- Nobody can draw the full map of which system calls which.
- A change to one system's API breaks connections nobody knew existed.
- Different bits of code send the same data to several systems in slightly different formats.
- Overnight batch jobs exist mainly to paper over systems that can't talk to each other in time.
- Outages spread, so one system going down causes errors in three others.
Warning signs you are over-engineering with events
- You're adding a broker to connect two systems that need neither buffering nor extra consumers.
- Every flow needs an immediate answer, so events are being bent into request-and-reply.
- Nobody can yet say who owns each event or what goes in it.
Can you use point-to-point and event-driven integration together?
Yes, and plenty of well-run estates do. A common pattern is direct API calls where an immediate answer is needed, such as stock and price checks at checkout, and events for everything after the order is placed: invoicing, fulfilment, customer notifications and reporting.
If you are moving from point-to-point to event-driven integration, do it one flow at a time. Start with the flow that hurts most, which is often orders or customer updates. Publish events for it alongside the existing connections, then move consumers across one by one, making sure each business action is only applied once. Check that processing and recovery actually work before you retire each old direct call. That keeps the risk low and proves the approach on one flow before you commit others.
What good integration looks like whichever approach you choose
The same habits make either kind of integration easier to live with.
- Agree which system owns each type of data.
- Define message and API formats clearly, and version them.
- Make every receiver cope with a message or request arriving twice.
- Log and monitor each flow end to end, with alerts that someone actually acts on.
- Keep an up-to-date map of what connects to what.
We help organisations decide where events make sense and build integrations that their own teams can support. Read more about our event-driven architecture and systems and API integration services.
Email [email protected] with your brief.