Real-Time Inventory Sync Architecture: Webhooks, Queues & Conflict Resolution

A single oversell costs an average of $47 in direct costs — refund processing, customer service time, marketplace defect penalties, and lost goodwill. For a mid-market seller processing 500 orders per day across four channels, even a 1% oversell rate burns $70,000 annually. The root cause is almost always inventory sync latency.

This post breaks down the architecture behind real-time inventory synchronization: how events propagate, how queues absorb traffic spikes, and how conflict resolution prevents the oversells that erode both margins and marketplace standing.

Key Takeaways

• Webhooks deliver sub-second notification but require idempotent handlers and verification
• Message queues decouple ingestion from processing — never process marketplace events synchronously
• Conflict resolution requires a central inventory ledger with delta-based updates, not absolute quantity overwrites
• Polling remains essential as a reconciliation mechanism even when webhooks are your primary sync method

---

Sync Methods Compared

Before diving into architecture, it helps to understand the three fundamental approaches to keeping inventory in sync across channels.

| Method | Latency | Reliability | Complexity | Use Case | |--------|---------|-------------|-----------|----------| | Polling | 1-15 minutes | High (you control timing) | Low | Legacy APIs, reconciliation | | Webhooks | Sub-second | Medium (delivery not guaranteed) | Medium | Real-time events, modern APIs | | Streaming | Sub-second | High (persistent connection) | High | High-throughput, enterprise | | Hybrid (webhooks + polling) | Sub-second primary, minutes fallback | High | Medium-High | Production recommendation |

The production recommendation is hybrid. Use webhooks for real-time updates and polling for periodic reconciliation. This gives you the speed of event-driven architecture with the reliability of scheduled verification.

---

Event-Driven Architecture for Inventory

An event-driven inventory system treats every stock-affecting action as an event: a sale, a return, a purchase order receipt, a warehouse transfer, a manual adjustment. These events are published to a message queue and consumed by workers that update the central inventory ledger and propagate changes to all channels.

The Event Flow

1. Event source emits an inventory event (e.g., Shopify fires an orders/create webhook)
2. Ingestion endpoint receives the event, validates authenticity, and publishes to the message queue
3. Processing worker consumes the event, updates the central inventory ledger in the ERP
4. Propagation workers read the updated quantity and push it to all other channels

This architecture has three critical properties:

• Asynchronous: The ingestion endpoint responds to the webhook immediately (HTTP 200) and processes later. This prevents webhook timeouts.
• Durable: The message queue persists events. If a worker crashes, the event is redelivered.
• Scalable: You can add workers to handle higher throughput without changing the ingestion layer.

---

Webhooks: Design and Pitfalls

Most modern eCommerce platforms support webhooks for inventory-related events. Shopify sends inventory_levels/update, Amazon SP-API offers notifications for order and inventory changes, and WooCommerce fires woocommerce_product_set_stock.

Webhook Verification

Every webhook handler must verify the request is authentic. Forged webhook payloads are a real attack vector — an attacker who can trigger inventory changes in your system can cause oversells or stockouts at will.

• Shopify: HMAC-SHA256 signature in the X-Shopify-Hmac-SHA256 header, verified against your app secret
• Amazon SP-API: SNS message signature verification
• WooCommerce: Webhook secret in the X-WC-Webhook-Signature header

Always verify before processing. Never skip verification in development — it is the one shortcut that becomes a production vulnerability.

Idempotency

Webhooks are delivered at least once, not exactly once. Network issues, retries, and platform quirks mean your handler will occasionally receive duplicate events. Your handler must be idempotent — processing the same event twice must produce the same result as processing it once.

Implementation patterns for idempotency:

• Idempotency key: Store the webhook ID (or a hash of the payload) in Redis with a TTL. If the key exists, skip processing.
• Delta operations: Never set absolute quantities from webhook data. Instead, apply the delta (e.g., "reduce by 1") so that a duplicate application is detectable.
• Database constraints: Use unique constraints on external event IDs to prevent duplicate order imports.

// Pseudocode: idempotent webhook handler
function handleInventoryWebhook(payload) {
  const eventId = payload.id
  const exists = await redis.set(eventId, '1', 'NX', 'EX', 86400)
  if (!exists) return // duplicate, skip

  await queue.publish('inventory.update', {
    sku: payload.sku,
    delta: payload.quantity_change,
    source: payload.source,
    eventId: eventId
  })
}

Webhook Failure Handling

When your endpoint returns a non-2xx status, marketplaces retry with exponential backoff. Shopify retries up to 19 times over 48 hours. Amazon retries for up to 3 days. If your system is down for maintenance, events queue up on the marketplace side and arrive in a burst when you come back online.

Your architecture must handle this burst. This is another reason to use a message queue — the queue absorbs the burst, and workers process events at a sustainable rate.

---

Message Queues for Inventory Events

The message queue is the spine of your inventory sync architecture. It decouples event ingestion from processing, provides durability, and enables independent scaling.

Queue Technology Selection

| Technology | Throughput | Durability | Complexity | Best For | |-----------|-----------|-----------|-----------|----------| | Redis Streams / BullMQ | 50K msg/sec | Configurable (AOF) | Low | Small-medium Odoo deployments | | RabbitMQ | 100K msg/sec | High (disk-backed) | Medium | Medium-scale, complex routing | | Apache Kafka | 1M+ msg/sec | Very High (replicated log) | High | Enterprise, event sourcing | | AWS SQS | Virtually unlimited | Very High (managed) | Low | AWS-native deployments |

For Odoo-based integrations, ECOSIRE uses BullMQ (built on Redis) as the default. It provides job prioritization, delayed jobs, rate limiting, and a dashboard for monitoring — all critical for inventory sync. The setup is minimal since Odoo deployments already use Redis for caching.

Queue Design Patterns

Topic-based routing: Separate queues for different event types. Inventory events go to inventory.updates, order events to orders.created, price changes to products.price_updated. This lets you scale workers independently — inventory sync gets more workers during peak hours while product updates process at their own pace.

Priority queues: Not all inventory updates are equal. A sale (decrement) is more urgent than a purchase receipt (increment) because oversells have immediate financial impact. Assign higher priority to decrement events.

Dead letter queue (DLQ): Events that fail processing after N retries move to a DLQ for manual inspection. This prevents poison messages from blocking the entire queue. Review DLQ entries daily — they often reveal data mapping issues or API changes.

---

Conflict Resolution Strategies

The hardest problem in inventory sync is concurrent updates. Two customers buy the last unit of a product at the same instant on different channels. Without conflict resolution, both orders succeed and you oversell.

Central Ledger Pattern

The most reliable approach is a central inventory ledger in your ERP that is the single source of truth. Channels report sales, and the hub recalculates available quantity.

Rule: Channels never set absolute quantities. They report deltas (sales, returns, adjustments), and the central ledger calculates the new available quantity and propagates it.

This eliminates a class of race conditions where two channels simultaneously read the same quantity, decrement it locally, and write back the same value — losing one of the decrements.

Reservation System

For high-velocity SKUs, even delta-based sync is not fast enough. A reservation system pre-allocates inventory to channels based on sales velocity and buffer rules.

| Channel | Allocation | Reserved | Available to Sell | Safety Buffer | |---------|-----------|----------|------------------|---------------| | Amazon | 40% | 40 units | 38 units | 2 units | | Shopify | 30% | 30 units | 28 units | 2 units | | eBay | 20% | 20 units | 18 units | 2 units | | Walmart | 10% | 10 units | 9 units | 1 unit | | Total | 100% | 100 units | 93 units | 7 units |

Safety buffers protect against sync latency. If Amazon sells 2 units in the time it takes for the sync to propagate, the buffer absorbs the difference.

Eventual Consistency

Multi-channel inventory is an eventually consistent system. At any given millisecond, channel quantities may not match the central ledger exactly. The goal is to minimize the consistency window (the time between a change and full propagation) and to manage the risk during that window with safety buffers.

Target consistency windows by priority:

• Sales (decrements): Less than 5 seconds
• Returns (increments): Less than 60 seconds
• Adjustments: Less than 5 minutes
• Full reconciliation: Every 6-12 hours

---

Polling as Reconciliation

Even with a webhook-first architecture, polling remains essential. Webhooks can be lost, delayed, or arrive out of order. A reconciliation job runs on a schedule, pulls the current state from each channel, and compares it to the central ledger.

Discrepancies are flagged and automatically corrected for small differences (less than 3 units) or escalated for manual review for larger gaps. This catches:

• Missed webhooks from marketplace outages
• Manual adjustments made directly in marketplace dashboards
• Rounding errors in quantity calculations
• Events lost during system maintenance windows

For a broader view of monitoring and failure detection, see Integration Monitoring: Detecting Sync Failures.

---

Scaling Considerations

As order volume grows, your inventory sync architecture faces new challenges.

Rate Limit Management

Every marketplace API has rate limits. When you need to update inventory across 5,000 SKUs on Amazon after a warehouse receipt, you cannot fire 5,000 API calls simultaneously. A rate-limited worker queue drips updates at the maximum allowed rate (Amazon SP-API: 10 requests/second for inventory feeds).

Batch vs Real-Time Tradeoffs

For catalogs exceeding 10,000 SKUs, full catalog sync shifts from real-time individual updates to batched feed submissions. Amazon's inventory feeds process thousands of SKUs in a single API call. Shopify's bulk operations API handles large-scale updates efficiently.

The architecture should support both patterns: real-time for high-velocity SKUs (top 20% by sales volume) and batched for the long tail.

Geographic Distribution

Selling across regions (US, EU, APAC) introduces latency challenges. A Redis instance in US-East adds 200ms round-trip to webhook processing from EU-based platforms. For global deployments, consider regional processing with cross-region replication of the central ledger.

For more on multi-channel architecture design, see the pillar post: The Ultimate eCommerce Integration Guide.

---

Frequently Asked Questions

How fast should inventory sync be to prevent oversells?

For most merchants, sub-30-second sync prevents the vast majority of oversells. The risk window is the time between a sale on one channel and the inventory update reaching other channels. With a 30-second window and 500 orders per day, the probability of a concurrent sale on the same SKU is below 0.1%. High-velocity SKUs (100+ sales per day per SKU) benefit from sub-5-second sync or a reservation system.

Can I use polling instead of webhooks?

You can, but polling on a 5-minute interval means your inventory is potentially 5 minutes stale on every channel. At moderate order volumes, this guarantees oversells. Polling works as a fallback and reconciliation mechanism, but webhooks should be your primary sync trigger for any channel that supports them.

What message queue should I use with Odoo?

BullMQ (built on Redis) is the recommended choice for Odoo deployments. Your Odoo infrastructure already includes Redis for caching, so no new infrastructure is needed. BullMQ provides job prioritization, rate limiting, delayed jobs, and a monitoring dashboard. For enterprise deployments exceeding 100,000 events per day, consider RabbitMQ or Kafka.

How do I handle inventory sync during marketplace outages?

Queue all outbound updates for the affected channel. When the marketplace comes back online, drain the queue in order. For inbound events (orders from the marketplace), the marketplace will replay webhooks when it recovers. Your idempotency layer ensures duplicate processing does not occur. Maintain safety buffers to cover the outage window.

What is the ideal reconciliation frequency?

Run full reconciliation every 6 to 12 hours for active SKUs and every 24 hours for the full catalog. More frequent reconciliation wastes API quota on slow-moving SKUs. Less frequent reconciliation allows drift to accumulate. Adjust based on your oversell rate — if you are seeing drift-related issues, increase frequency.

---

What Is Next

Inventory sync is the technical foundation of multi-channel eCommerce, but it does not exist in isolation. Once your inventory is accurate across channels, the next step is optimizing how orders flow through your fulfillment network.

Explore ECOSIRE's integration services for production-ready inventory sync connectors for Odoo, or contact our team to discuss your specific architecture requirements.

---

Published by ECOSIRE — helping businesses scale with AI-powered solutions across Odoo ERP, Shopify eCommerce, and OpenClaw AI.