I posted a PHP solution, the community suggested Go, and I went for it: the "Drop-in Buffer" for webhooks is now a single binary

On October 24, 2026, developer Edson Ferreira published a critical update on the TabNews platform for a project aimed at B2B automation infrastructures. The initiative, dubbed "Drop-in Buffer," was designed to solve a common bottleneck in companies using the n8n tool coupled with messaging systems, such as WhatsApp via Evolution API. After creating a PHP prototype to prevent webhook bursts from causing server crashes due to memory shortages and CPU spikes, Ferreira received direct feedback from the community, which motivated him to rewrite the entire system in the Go language. The result is a single binary that acts as a high-performance buffer between the data source and the automation consumer.

The solution replaces the need to implement heavy message queuing infrastructures—such as RabbitMQ, Kafka, or Redis—offering a low-computational-cost alternative specifically designed for lean Virtual Private Servers (VPS), where every gigabyte of RAM usage directly impacts the operation's profit margin.

Context and background: from PHP to a single Go binary

The original architecture designed by Ferreira consisted of a script of approximately 20 lines in PHP connected to a SQLite database. The initial goal was simple: to act as a barrier that receives requests from the Evolution API, stores the data in the local database, and responds with a 200 OK status instantly, freeing up the connection. n8n, which was previously bombarded directly, started fetching this data at its own pace.

However, the original publication revealed vulnerabilities pointed out by TabNews users. The developer under the pseudonym "@plugandship" identified three critical flaws in the PHP model:

• Exposure of sensitive data: The .sqlite file was stored in the web server's public folder, allowing third parties to download the WhatsApp conversation history if they guessed or discovered the file path.
• Risk of duplication: There was a lack of strict record reservation control. If n8n took too long to process a batch, the next request could fetch the same pending messages.
• Concurrency bottleneck: During extreme spikes, simultaneous PHP requests caused the "database is locked" error in SQLite.

At the same time, user "@Oletros" suggested that PHP be treated only as a Proof of Concept (PoC) and that the definitive solution be migrated to Go. Ferreira welcomed the criticism and the suggestion, developing a new architecture that takes advantage of goroutines (lightweight threads in the Go ecosystem) and compiles all the code into an executable file that does not depend on external web servers like Apache or PHP-FPM.

Concrete data: the technical anatomy of the new Drop-in Buffer

The updated version of the Drop-in Buffer brings specific technical modifications that ensure the stability of the automation. The main structural change is the use of the modernc.org/sqlite driver. This driver is written in pure Go, which eliminates the dependency on CGO (C Go) and C compilers, allowing direct cross-compilation (e.g., from Windows to Linux) without friction in the deployment environment.

The technical parameters configured by Ferreira in the new system include:

• Batch capacity: The system allows limit configuration through the limit=50 parameter in the consumption URL. The default is 50 items per request, but the supported ceiling is up to 500 items.
• Connection timeouts: The Go server has been configured with a ReadTimeout of 10 seconds for reading requests, preventing slow connections from hogging network resources.
• SQLite settings: To handle concurrency and avoid the locked database error, Ferreira implemented the pragma variables journal_mode(WAL) (Write-Ahead Logging) and busy_timeout(5000).
• Connection control: The application explicitly defines a maximum of one open connection to the database (SetMaxOpenConns(1)), forcing writes to operate in a strict single-file queue and eliminating locks originating from the process itself.

Practical application: how to implement isolation in your company

The implementation of the buffer changes the architectural flow of B2B integrations, isolating the event-generating source from the logical processing engine (n8n). For a company operating AI-powered conversational agents via WhatsApp, the implementation follows a four-step flow.

1. Webhook Interception: The Evolution API is configured to send messages to the POST /webhook endpoint exposed by the Go binary. The buffer processes payloads of up to 10MB (supporting base64 media), writes them to the SQLite database, and returns HTTP status 200 immediately.
2. Controlled Ingestion: The n8n server is configured to, for example, trigger a Cron job every minute, making a POST /fila/pegar?limit=50 request. The buffer uses the database's RETURNING instruction to change the status of messages from 'pending' to 'processing', ensuring data reservation in a single transaction and preventing duplication.
3. Cleanup and Maintenance (Housekeeping Goroutine): Since the Go binary is a continuous resident process (unlike PHP, which dies with every request), the system runs a background thread that identifies records stuck for more than 10 minutes in 'processing' status and returns them to the queue as 'pending'. This eliminates the need for OS-level cron jobs.
4. Confirmation and Discard: Once the n8n flow processes the customer's message asynchronously, the automation platform makes a final call to the POST /fila/{id}/processado (on success) or POST /fila/{id}/erro (on failure) endpoints, ensuring lifecycle consistency for the request without needing native n8n integration with SQLite nodes.

Impact on the B2B automation sector

The development documented by Ferreira on TabNews highlights a trend in the B2B and SMB (Small and Medium Business) automation market: the search for efficiency beyond the "tech hype." Often, automation consulting firms propose inserting Apache Kafka or Redis clusters to mediate events. Although they are the standard for companies dealing with millions of events per second, these tools require specialized maintenance, high-RAM instances, and exponentially increase the attack surface and infrastructure cost.

Using the Go + SQLite combination shares the same fault-tolerance principles for medium-sized workflows but centralizes the logic in a single binary file that consumes only a few megabytes of memory. This directly affects development agencies in the Latin American market, which operate white-label solutions of Evolution API and n8n on low-cost instances from Hetzner or DigitalOcean, allowing them to host dozens of clients on the same machine without the risk of chain instabilities caused by a single client's WhatsApp marketing campaign.

What is still unknown

Although the solution solves the architectural flaws of the PHP version, the material published on TabNews leaves two operational points open that require additional validation:

• Performance under quantified extreme load: The author reports significant qualitative improvements regarding n8n crashes, but there is no formal benchmark measuring the exact throughput of requests per second (RPS) that the SetMaxOpenConns(1) constraint in SQLite can sustain before queuing starts causing timeouts at the source (Evolution API).
• Backup and persistence strategy: With the database being the single temporary point of failure, the recommended strategy for backing up the buffer_webhooks.sqlite file on production servers was not detailed to prevent the loss of webhooks in case of file system corruption on the VPS.

What to expect next

With the code and endpoint specifications opened up by the community, it is expected that automation developers will create native n8n templates that already incorporate the pegar (fetch), processado (processed), and erro (error) logic out of the box to connect to Drop-in Buffer binaries. Furthermore, the ease of deploying a single Go executable should boost the adoption of the modernc.org/sqlite driver in other middleware and microservices developed by independent agencies to mitigate Node.js limitations in heavy I/O operations in serverless automations.

Frequently Asked Questions

Why does n8n crash when receiving many direct webhooks? n8n, built on Node.js, features asynchronous processing, but each workflow execution consumes considerable RAM resources. A burst of webhooks forces the operating system to simultaneously allocate memory for dozens of workflow instances, quickly exhausting VPS limits and crashing the service (OOM - Out of Memory).

What is the main advantage of the Go version compared to PHP in this case? Go compiles into a single binary and works as a resident process. This allows it to hold thousands of simultaneous connections using lightweight goroutines and enables the execution of background tasks (like cleaning up stuck items in the queue) without needing to configure external tools like the Apache server or OS-level Cron job schedulers.

How was the database exposure problem solved? The Go architecture consolidates the HTTP server within the code itself, exposing only explicitly programmed routes (/webhook, /fila/pegar, etc.). The SQLite file (.sqlite) resides on the local file system but is never directly mapped to a public-facing folder, eliminating the security flaw that allowed database downloads via browser.