Backpressure

Wat is backpressure?

Backpressure gebeurt wanneer het deel van een systeem dat data ontvangt het tempo niet volgt van het deel dat data stuurt, en een manier krijgt om dat te zeggen. De trage kant geeft aan dat hij vol zit, en de snelle kant reageert door te vertragen, data even in een buffer te houden, of een stuk bewust te laten vallen. De naam komt uit de loodgieterij: duw je water sneller door een buis dan het er aan het einde uit kan, dan bouwt de druk zich terug op richting de bron.

Het probleem is makkelijk voor te stellen. Een zender produceert 10.000 records per seconde. De ontvanger die ze inleest, verwerkt er 3.000 per seconde. Zonder flow-control moet dat gat van 7.000 records elke seconde ergens naartoe. Het stapelt op in het geheugen tot de ontvanger vastloopt, en sleurt vaak de hele pijplijn mee. Backpressure is de afspraak die dat gat belet om eindeloos te groeien.

Je komt dit tegen overal waar data van een snel deel naar een traag deel beweegt: platformen voor streaming data, systemen met een message queue, netwerkverbindingen en de reactieve libraries in moderne applicaties. Het is een gezond signaal, geen storing. Een pijplijn die backpressure kan toepassen, zakt netjes terug onder druk in plaats van om te vallen.

Wat er misgaat zonder backpressure

Zonder een manier om terug te duwen, heeft de overtollige data enkel slechte plekken om naartoe te gaan.

De eerste is het geheugen. Ongelezen data verzamelt zich in een wachtrij die groeit tot het proces gekild wordt. De tweede is vertraging: nog voor het vastloopt, antwoordt een dienst met een enorme achterstand op elke vraag traag, want elk nieuw item moet achteraan aanschuiven. De derde is dataverlies, en dat is de ergste, want het gebeurt in stilte. Een buffer loopt over, records worden zonder boe of ba weggegooid, en niemand merkt het tot een rapport tekortkomt.

Net dat is de winst van backpressure: een verborgen, catastrofale storing wordt een zichtbare, gecontroleerde. Een pijplijn die vertraagt onder druk, vertelt je iets nuttigs. Een pijplijn die stilletjes data weggooit, liegt tegen je.

Hoe systemen het toepassen

Er zijn een paar eerlijke antwoorden op meer data dan je aankan, en een echt systeem combineert ze meestal.

• De zender vertragen. De properste optie: zeg de bron dat hij minder stuurt tot de achterstand weg is. Dat werkt alleen als je de bron ook echt kan doen wachten, en dat is niet altijd zo.

• Bufferen. Hou het teveel in een wachtrij en werk het weg. Dat vangt korte pieken goed op, maar een buffer is uitstel, geen oplossing. Duurt de overbelasting langer, dan loopt de buffer vol en sta je weer voor de keuze tussen blokkeren en weggooien.

• Laten vallen. Gooi bewust data weg waar dat mag. Voor een live dashboard met een geschat cijfer maakt een gemiste meting niks uit. Voor betalingen is data laten vallen geen optie.

Het diepere onderscheid is push tegenover pull. In een push-model stuurt de zender wanneer hij wil, dus moet backpressure er bovenop gebouwd worden. In een pull-model vraagt de ontvanger pas de volgende batch als hij er klaar voor is, waardoor flow-control ingebouwd zit: wie niks vraagt, krijgt niks. De Reactive Streams-specificatie, die onder de reactieve libraries in de Java- en .NET-wereld ligt, giet dat in regels. Een ontvanger roept request(n) aan om te zeggen hoeveel items hij aankan, en de zender mag niet meer sturen dan die openstaande vraag. TCP doet al decennialang net hetzelfde: de ontvanger geeft een venster door dat zegt hoeveel de zender mag versturen voor hij op een bevestiging wacht.

Backpressure in Apache Kafka

Apache Kafka gaat hier soepel mee om, want het is van nature pull-based. Zenders schrijven records naar een duurzame, geordende log, en ontvangers halen die op in hun eigen tempo. Is een ontvanger traag, dan gaat er niks verloren en loopt het geheugen niet vol: de records blijven gewoon op schijf in de log staan, en de positie van de ontvanger valt verder achter op het nieuwste record. Die afstand heet consumer lag, en het is het belangrijkste signaal dat backpressure aan het opbouwen is.

Omdat de log de data veilig bijhoudt, is het aan de ontvanger zelf om niet meer af te bijten dan hij kan kauwen. De Kafka-client laat een ontvanger specifieke partities pauzeren en hervatten, zodat een applicatie die achterop raakt kan stoppen met nieuwe records ophalen tot ze de rest verwerkt heeft, en daarna verder gaat. De consumer lag over de tijd volgen, vertelt je of de ontvanger bijblijft, aan het inhalen is of terrein verliest. Een lag die alleen maar groeit, betekent dat de ontvanger structureel te traag is en meer instances of snellere verwerking nodig heeft, geen grotere buffer.

Waar moet je op letten bij backpressure

Een buffer is geen oplossing. Meer geheugen of een grotere wachtrij koopt tijd, meer niet. Is de ontvanger structureel trager dan de zender, dan loopt elke buffer vroeg of laat vol. De echte fix is meer capaciteit bij de ontvanger of minder inkomend werk.

Stilletjes weggooien vreet aan het vertrouwen. Kies je ervoor om bij overbelasting data te laten vallen, dan moet die keuze zichtbaar zijn: geteld, gelogd en gekend door wie de output leest. Weggegooide records die niemand kent, worden verkeerde cijfers die niemand kan verklaren.

Backpressure verplaatst de flessenhals, het verwijdert ze niet. Een snelle zender vertragen kan de druk een stap verder naar boven duwen, naar wat die zender voedt. Volg de hele keten in plaats van elke schakel apart te bekijken.

Niet alles kan wachten. De zender vertragen veronderstelt dat de bron zich laat afremmen. Een sensor, een beursfeed of een externe partner stuurt misschien gewoon door, en dan val je terug op bufferen of laten vallen. Weet welke van je bronnen je kan vragen om te vertragen voor je het ontwerp bouwt op de aanname dat ze dat kunnen.