Een queue is een rij taken die op hun beurt wachten en in volgorde worden afgehandeld, een voor een. In software laat een queue een systeem meer werk aannemen dan het op dat moment aankan, door elke klus te parkeren tot er weer ruimte is om hem op te pakken.
Denk aan de kassa van een supermarkt. Klanten sluiten achteraan aan, de caissière helpt de voorste, en niemand hoeft op de milliseconde van binnenkomst te worden afgerekend. Een queue doet hetzelfde voor software: als er in één minuut duizend bestellingen binnenkomen, zet de app ze netjes in de rij en verwerkt ze gestaag in plaats van te crashen onder de drukte. Dit patroon is de ruggengraat van event-driven architectuur, waar losse delen van een systeem met elkaar praten via berichten in plaats van elkaar rechtstreeks aan te roepen, en het past mooi bij microservices die elk één taak hebben.
De winst zit in veerkracht. Is een vervolgservice even uit de lucht, dan houdt de queue het werk veilig vast tot hij weer draait, zodat er niets verloren gaat. En de gebruiker krijgt meteen antwoord terwijl het trage deel buiten beeld gebeurt.
Er is één valkuil die teams die nieuw zijn met queues nogal eens raakt. Mislukt een taak halverwege en wordt hij opnieuw geprobeerd, dan kan hetzelfde werk twee keer draaien: een kaart twee keer belast, een mail twee keer verstuurd. Daarom leunen queue-systemen zwaar op idempotency, zodat elke taak veilig te herhalen is zonder dubbel effect. Een bevestigingsmail die drie keer uitgaat is vervelend. Een betaling die drie keer draait is een terugstorting en een telefoontje.
Bij TopDevs gebruiken we queues om de systemen van klanten responsief te houden onder druk, zodat een druk uur er voor je klanten net zo uitziet als een rustig uur.
