Queues, webhooks and events between your systems
We build asynchronous exchange between systems: queues, webhooks and events with retries, duplicate control and a place to see and reprocess whatever failed.
Who it's for
For companies whose systems talk through webhooks and direct calls, and lose data when one of them goes down.
What it solves
- A webhook arrived while the system was down and was lost.
- The notice for a Pix payment arrives twice and the order is marked as paid twice.
- One slow system holds up the others, because they all wait for its reply.
- When something fails, nobody knows which messages were left behind.
What we do
- Event catalogue
- Which events exist, who publishes them, who consumes them and the format of each.
- Receiving webhooks
- The webhook is accepted, verified and queued at once, then processed calmly afterwards.
- Retries with growing waits
- Temporary failures are tried again, with longer and longer intervals.
- Duplicate control
- The same message processed twice gives the same result, with no double effect.
- Dead-letter queue
- Whatever still fails after the retries is set aside, with the reason, for analysis.
- Reprocessing
- Failed messages can be resent after the fix, one by one or in bulk.
- Queue monitoring
- Queue size, delay and errors visible on a dashboard, with automatic alerts.
What you get
- An event catalogue with the format and version of each message
- Queues and consumers in production, with retries and duplicate control
- A dead-letter queue and a reprocessing tool
- A dashboard and alerts for queue delays and errors
- Tests that simulate outages, delays and repeated messages
How we do it
Mapping
Which systems exchange messages today, how, and where messages have already been lost.
Design
Events, formats, queues and retry rules defined and written down.
Implementation
Queues, consumers and webhook intake, with failure tests.
Running in parallel
The new flow runs alongside the old one until it shows it loses nothing.
Operations
Dashboard, alerts and a runbook for your team to reprocess messages.
Technology examples
- RabbitMQ
- Kafka
- Amazon SQS
- Google Cloud Pub/Sub
- AsyncAPI
- CloudEvents
- Webhooks
Related services
FAQ
RabbitMQ, Kafka or a cloud queue?
It depends on volume, how long messages must be kept and who will operate it. A managed cloud queue is usually simpler to run.
Can we be sure no message is ever lost?
No system removes every failure. What we do is store each message before processing it, retry it and keep failures visible, so nothing disappears silently.
Do we need to change our current systems?
Sometimes only a little: many already send webhooks or accept calls. Where that is not possible, we put an adapter in front of the system instead of changing it.
Is personal data exposed in the queues?
We take that into account: messages carry only what is needed, and access to the queues and error logs is restricted.
Write to Balkan
Talk to us about your project