Event Ordering: Apply Sync Changes in Sequence

In a data sync, the order of changes matters. If a customer's status changes from active to on hold and then back to active, applying those two updates in the wrong order leaves the record on hold, the opposite of the truth. If a record is created and then updated, processing the update first can fail or create a duplicate. Yet many of the channels integrations use, from webhooks to queues to parallel workers, do not deliver events in strict order. Event ordering is the problem of applying changes correctly even when they arrive out of sequence. This guide explains why disorder happens, what common queues and logs actually guarantee and how to design consumers that stay correct anyway.

Why events arrive out of order

Disorder creeps in from many places:

• Webhooks are sent independently, so a later event can arrive before an earlier one if the first is delayed or retried
• Queues may not guarantee order, and failed messages are redelivered after newer ones
• Several workers process messages in parallel and finish at different times
• Retries after timeouts deliver an old event again after newer ones have been applied
• Different source systems have different clocks, so their timestamps cannot be compared reliably

Any of these can cause a stale update to overwrite a newer one, which is the most damaging kind of ordering problem because it is silent.

Know what your channel guarantees

Ordering guarantees vary by product and configuration, so check the documentation of what you use rather than assuming. Two examples show the range.

Amazon SQS standard queues provide best-effort ordering. The AWS documentation explains that SQS attempts to deliver messages in the order they were sent but does not guarantee it, that messages may arrive out of order especially under high throughput or failure recovery, and that applications where order matters should handle reordering themselves or use FIFO queues. Standard queues also provide at-least-once delivery, so a message may occasionally be delivered more than once (AWS: Amazon SQS queue types).

Apache Kafka orders events within a partition. The Kafka introduction explains that events with the same key, such as a customer ID, are written to the same partition, and that any consumer of a topic partition will always read its events in exactly the order they were written (Apache Kafka: Introduction). Ordering is per partition, not across the whole topic.

The common theme: ordering, where it exists, is usually per key or per group, not global. That is enough for most syncs, because what matters is the order of changes to the same record.

Event ordering by record key

Design the pipeline so that all events for one record travel through the same ordered lane:

• Use the record ID as the partition key or message group, so its events stay in sequence
• Process each key with one worker at a time, even if many keys are processed in parallel
• Keep retries for a key in order, by pausing that key rather than moving a failed event to the back while newer ones proceed

Our guide to choosing a message broker compares the ordering options of common brokers in more detail.

Use versions to reject stale updates

Even with ordered lanes, some disorder will slip through: a webhook from a source system, a manual replay or a redelivered message. Make consumers defend themselves by comparing versions:

• Include a version number, sequence number or reliable source timestamp in every event
• Store the last applied version on the target record
• Apply an event only if its version is newer than the stored one; otherwise skip it and log the skip

This turns ordering from a delivery guarantee into a property of the data. It also makes consumers idempotent, because a repeated event has a version that is not newer.

Prefer version numbers generated by the source system for that record. Timestamps work only if they come from a single clock and have enough precision; timestamps from different systems should not be compared.

Fetch the current state when in doubt

Another robust approach is to treat events as notifications rather than data. When an event arrives saying a record changed, the consumer fetches the current state of that record from the source and applies it. Order then matters much less, because every fetch returns the latest data. The cost is an extra API call per event, which may hit rate limits for busy records, so combine it with deduplication of events received close together.

Handle gaps

Sometimes an event is missing, such as a create that never arrived before an update. Decide how consumers respond: fetch the full record from the source, park the event and retry later, or send it to a dead letter queue for investigation. Do not create partial records from an update event that lacks required fields. Record each gap with the event details, so repeated gaps from one source can be raised with its owner.

Worked example: hypothetical ordering decisions

The table below shows hypothetical ordering decisions for three event types in a CRM and accounting sync. It illustrates the choices, not tested settings.

Event typePartition or group keyStale-update checkOn gap or doubtCustomer updatedCustomer IDSource version numberFetch current customer from sourceInvoice status changedInvoice IDStatus sequence in source systemFetch invoice; never move status backwards automaticallyPayment recordedInvoice IDPayment ID already appliedSkip duplicate; alert if invoice missing

Test with disorder on purpose

Ordering bugs rarely appear in simple tests. Build tests that deliver events out of order, deliver duplicates and drop events, then check that the target ends in the correct state. Our guide to the outbox pattern covers publishing events in order from the source side, which complements these consumer-side defences.

Monitor for ordering problems

Track how often consumers skip stale events, how often they fetch current state because of gaps and how many events reach the dead letter queue. A rise in skipped stale events can signal a misconfigured partition key or a source that started sending events in parallel. Review these numbers after changes to the pipeline, such as adding workers or changing partition counts, because those changes can quietly break ordering assumptions that held before.

Frequently Asked Questions

What is event ordering in data sync?

It is making sure changes to the same record are applied in the order they happened, even when events are delivered out of sequence.

Do message queues guarantee order?

Some do, often only per key or group. Amazon SQS standard queues provide best-effort ordering, while Kafka orders events within a partition. Check the guarantees of the product and configuration you use.

How do I stop an old update overwriting a newer one?

Include a version number in each event, store the last applied version on the record and skip any event that is not newer.

Is fetching the current record a good alternative?

Often, yes. Treating events as notifications and fetching current state avoids most ordering issues, at the cost of extra API calls.

Apply changes in the right order

We design sync pipelines with keyed ordering, version checks and gap handling so data stays correct under real-world conditions. See our real-time CRM and database synchronization service, or talk to us about event ordering.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.