Pub/sub, een afkorting van publish en subscribe, is een berichtenpatroon waarbij het systeem dat een gebeurtenis stuurt en de systemen die erop reageren nooit rechtstreeks met elkaar praten. De verzender publiceert een bericht naar een kanaal met een naam, een topic, en elk systeem dat zich op dat topic heeft geabonneerd krijgt zijn eigen kopie. De publisher weet niet wie er meeluistert en dat hoeft ook niet.
Denk aan een podcast. De host neemt een aflevering op en publiceert die. Elke luisteraar die zich heeft geabonneerd krijgt hem automatisch, of dat er nu vijf zijn of vijftigduizend. De host belt niet elke luisteraar, en luisteraars kunnen erbij komen of weggaan zonder dat de host iets verandert. Die losse koppeling is precies de bedoeling, en wordt geregeld door een message broker die ertussen zit en elk bericht naar de juiste subscribers stuurt.
Dit patroon is de ruggengraat van event-gestuurde automatisering. Eén gebeurtenis, zeg een geplaatste order, kan tegelijk facturatie, verzending en rapportage in gang zetten, elk onafhankelijk. Voeg je later een nieuwe subscriber toe, dan hoeft er verder niets te veranderen.
De keerzijde is dat die losse koppeling het moeilijker maakt om te volgen wat er gebeurt. Omdat de publisher nooit iets terughoort, weet die niet of een subscriber het bericht echt verwerkte of stilletjes crashte. Eén subscriber kan dus falen terwijl alles van buiten prima lijkt. Daarom leunen pub/sub-systemen in productie op retries, dead-letterqueues voor berichten die blijven mislukken, en goede logging, zodat een verloren event niet ongemerkt verdwijnt.
Bij TopDevs grijpen we naar pub/sub als één gebeurtenis meerdere losse reacties moet starten, zodat je systemen los gekoppeld en makkelijk uit te breiden blijven.
