From naive webhooks to durable sync: Queue-based and event-driven data reconciliation patterns

Summary

Maintaining consistent product data between an internal catalog and Stripe becomes difficult when outages, throttling, high volumes, and changes from both systems create reconciliation failures. The post compares a naive one-way flow, in which a Lambda calls the Stripe API with no persistent synchronization record, with a queue-based design that durably stores changes, controls processing rate, retries failures with exponential backoff, and sends persistent failures to dead-letter queues. For bidirectional synchronization, it contrasts periodic ETL, using extraction, transformation, and loading, with an event-driven model based on Stripe Event Destinations, EventBridge, SQS, and symmetrical events from internal systems. The conclusion is that durable, observable queues and event-driven processing provide buffering, auditability, near-real-time propagation, independent change processing, and more graceful scaling for distributed reconciliation.

Context

The problem is keeping product data consistent between an internal system and Stripe. One-way synchronization can lose changes during Stripe outages, suffer Lambda throttling or API quota failures, and provide little visibility into failed updates. Bidirectional synchronization adds schema changes, conflict resolution, deletion cases, and reconciliation delays to the limitations of periodic ETL.

Approach / What changed

The post presents queue-based processing for one-way synchronization, using durable queues, controlled worker rates, exponential-backoff retries, batch failure handling, and dead-letter queues. For bidirectional synchronization, it proposes Stripe Event Destinations through an EventBridge partner event bus, durable messaging with SQS and EventBridge, matching event flows from internal systems, and dedicated synchronization services that update the opposite system.

Takeaways

• A direct Lambda-to-Stripe call can lose synchronization changes during outages because it has no persistent record or built-in retry mechanism.
• Queue-based processing retains messages until confirmed success, buffers update spikes, exposes backlog through queue depth, and allows rate limiting and retry behavior to be managed separately from the product service.
• Event-driven bidirectional reconciliation uses Stripe Event Destinations and internal change events to reduce synchronization windows from hours or days to seconds or minutes while providing an audit trail.

Related reading