Externe diensten kiezen zelf wanneer ze 500 webhooks tegelijk versturen. Jouw server niet.
SendGrid stuurt na een grote campagne in één keer al je bounce- en deliverability-meldingen door. Stripe doet hetzelfde na een batch-uitbetaling. Jouw server krijgt de volle laag en gaat in de knel — precies op het moment dat je deze data het meest nodig hebt. WebhookFlow zet zich tussen jullie en levert in een tempo dat jouw applicatie aankan.
Waarom webhook-pieken jouw infrastructuur onderuit halen
Providers versturen in bursts, niet gespreid
SendGrid, Mailgun, Stripe, Shopify — ze verzamelen events intern en pushen ze in grote bundels. Een mailcampagne van 50.000 ontvangers kan in minuten resulteren in duizenden webhook-aanroepen. Voor jouw server is dat een spike die nergens uit te lezen was.
Time-outs leiden tot herhaalde verzendingen
Reageer je te traag, dan herhaalt de provider. Drie keer, vijf keer, soms tot dertien keer. De spike die je niet aankon wordt versterkt tot een werkelijke storm. Je server raakt verder achter, je metrics rapporteren foutpercentages, en jouw applicatie wordt onbeschikbaar voor échte gebruikers.
Schaalbaar maken kost meer dan de pieken waard zijn
Je server permanent oversized maken voor één spike per dag is duur en zonde. Auto-scaling start vaak te traag op (een container starten kost seconden, de spike duurt enkele tellen). Een buffer ertussen is structureel goedkoper én betrouwbaarder.
Wat je mist krijg je vaak niet meer terug
Geen 200-respons binnen de retry-tijd? Veel providers geven het op en gooien het event weg. Dat is data die je voor je administratie, factuur-flow of klantcommunicatie nodig had. Permanent verloren.
Hoe WebhookFlow je server beschermt tegen pieken
Onmiddellijk accepteren, gecontroleerd doorzetten
WebhookFlow geeft elke binnenkomende webhook direct een 200-respons. De provider is tevreden, herhalingen blijven uit. Daarna zetten wij het bericht in een wachtrij en bezorgen het aan jouw server in een tempo dat je hebt ingesteld.
Rate-limiting per ontvanger
Stel een maximum in: bijvoorbeeld 50 doorgezette webhooks per seconde naar je productieserver. Komen er meer binnen, dan wachten ze in de buffer tot het volume zakt. Geen plotselinge piek meer naar jouw infrastructuur.
Herhaalpogingen bij downtime
Is je server even niet bereikbaar? WebhookFlow houdt de meldingen vast en probeert het automatisch opnieuw — met exponentiële backoff, zodat een herstellende server niet meteen weer onder de voet wordt gelopen.
Volledige audit-log
Elke ontvangen, doorgestuurde en mislukte poging staat geregistreerd. Je ziet exact hoeveel er in de buffer wachten, hoe lang gemiddeld, en welke berichten een retry hebben gehad. Inzicht in wat er echt door je systeem stroomt.
Veelgestelde vragen over webhook-pieken
Hoe hoog is een typische SendGrid-piek?
Voor een nieuwsbriefverzending naar 50.000 ontvangers krijg je binnen enkele minuten tussen de 49.000 en 60.000 events — delivered, opens, clicks, bounces en spam-rapporten gecombineerd. SendGrid pusht die in batches met soms 100+ events per seconde. Voor servers die normaal op enkele requests per seconde draaien is dat een orde van grootte teveel.
Werkt dit ook voor Stripe en Shopify?
Ja, het patroon is hetzelfde. Stripe pusht na een batch-uitbetaling of bij een grote refund-actie een burst van transactie-events. Shopify doet dit bij Black Friday of flash sales — duizenden order-events in korte tijd. WebhookFlow is provider-agnostisch en bufferert elke type webhook.
Wat als de buffer zelf vol raakt?
De wachtrij is gedimensioneerd op realistische pieken (tienduizenden events per minuut). In de praktijk vult de buffer tijdens een piek en leegt zichzelf binnen seconden tot minuten weer. Wij monitoren dit en geven een melding als de wachtrij langer dan ingestelde drempels blijft groeien, zodat je tijdig actie kunt ondernemen.
Voegt deze tussenlaag geen vertraging toe?
Voor de doorzending naar je server: nee, tenzij je bewust rate-limit. Een webhook wordt bij ons binnen milliseconden ontvangen en bij rustige load ook binnen milliseconden doorgezet. Wat je toevoegt is een buffer voor situaties waar normaal data verloren zou gaan — een goede ruil.
Kan ik ook prioriteren tussen verschillende soorten webhooks?
Ja. Je kunt per webhook-bron (URL of provider) verschillende rate-limits en prioriteit instellen. Betalingsbevestigingen kun je bijvoorbeeld met hogere prioriteit doorzetten dan delivery-statussen van marketing-mails.
Geen plat-bombardement meer door webhook-pieken
WebhookFlow is in ontwikkeling en zoekt beta-gebruikers. Meld je aan voor vroege toegang en help mee bepalen wat de volgende functies worden.