Delays, timeouts, and lost requests when delivering webhooks from third-party services — CRMs, payment gateways, or delivery services — inevitably lead to out-of-sync orders, stuck payments, and database deadlocks. Synchronous processing of incoming HTTP requests directly in the online store's handlers overloads the server and makes the system vulnerable during peak loads.
Why synchronous webhook processing destroys e-commerce infrastructure
When an external service sends a webhook with a notification about a successful payment or an order status change, the standard backend on WordPress/WooCommerce or custom PHP often tries to immediately perform heavy operations: write data to the database, update product stock, send an email, or contact a third-party API via a synchronous request. If such events arrive several dozen per second, critical problems arise:
- Connection timeouts: The external system waits for a response (usually within 3–5 seconds). If the database is busy, the request is aborted and the service starts a retry storm.
- Database Deadlocks: Parallel requests to update the same orders table cause transactions to deadlock.
- Data loss: If the server crashes during synchronous execution, the event disappears irretrievably, as the sender may not have received the confirmation code.
200 OK.
Asynchronous Event and Queue Architecture
The only reliable way to stabilize the operation of an online store under load is to decouple the process of receiving the event and the process of executing it. The webhook endpoint should perform only minimal checks, store the raw payload (raw data) in a queue, and instantly return a success status. 200 OK. The processing itself takes place in the background.
Key elements of reliable integration
- Signature validation (HMAC): Each incoming request must be verified against a cryptographic hash to avoid data tampering and unauthorized script execution.
- Idempotency: External services often resend webhooks in the event of network failures. The system must recognize the unique transaction identifier and ignore duplicates.
- Event Queue: Using a database queue table or a Redis/RabbitMQ-based queue for sequential event processing.
Decision Framework: How to choose an approach to handling webhooks
Not every online store needs complex Redis-based queues. The architectural solution depends on the volume of operations:
- Synchronous execution: Allowed only for light, non-blocking tasks with a guaranteed response time of up to 1 second if the store processes less than 50 orders per day.
- Asynchronous queue (Database or Queue Worker): A must for stores that process more than 50 orders per day or are integrated with heavy external ERP and CRM systems. This protects the site from downtime during promotions or sales.
A practical look at development and support
Building stable API integrations requires not only writing code, but also properly configuring the server environment, monitoring queues, and testing loads. Using structured approaches to fixing errors helps avoid emergency situations on a “live” project. The reliability of e-commerce solutions directly depends on regular backend auditing and database query optimization.
Frequently Asked Questions
- What to do if an external CRM constantly duplicates webhooks?
Implement idempotence checking at the event handler level using a unique transaction or order ID. - Is it possible to do without Redis for webhook queue in WooCommerce?
Yes, for medium loads, you can implement a queue based on a MySQL table with careful field indexing, but for high loads, it is recommended to use system background processes. - Why is it important to respond with a 200 OK code instantly?
Most payment systems and CRMs consider a request as failed and retry it if they don't receive a response within a few seconds. This creates artificial load on the server.
If you need website development, refinement or technical support, please contact VORONOV Solutions for task evaluation.
English 
Ukrainian