Thin versus fat events?

De voor- en nadelen van thin & fat events

Beide varianten hebben voor- en nadelen. Het is bij het toepassen van verschillende design patterns goed te weten wat deze voor- en nadelen zijn.

• Doordat in thin events niet alle event data meegestuurd worden, moet de consumer van het event weten bij welke producer of ander systeem de (aanvullende) data opgehaald kunnen worden. Het voordeel van de ontkoppeling (decoupling) tussen systemen doe je hier (deels) mee teniet.
• Fat events bevatten alle data, maar deze data zijn slechts zo actueel als het event zelf. Bij thin events worden systemen zo ingericht dat ze op het moment van ontvangen (of consumeren) van het event de laatste data ophalen.
• Voor fat events moet je goed nadenken over welke data in de event body opgenomen worden. Bij thin events speelt dit minder omdat je in thin events vaak alleen een identifier/uri meestuurt en de aanvullende data na consumptie van het event apart opgehaald worden.
• De hoeveelheid data die je in een fat event meestuurt heeft over een langere periode eerder de neiging te groeien dan te krimpen. Fat events worden doorgaans snel ‘dikker’ en zelden ‘dunner’.
• Als je data van andere systemen in dezelfde event stream af wil schermen kan het een optie zijn deze door de consumer - na het onvangen van een thin event - in een losse (geauthentiseerde) request op te laten halen.

Na het lezen van deze voor- en nadelen valt op dat er geen goed of fout is. Leidend bij de keuze voor een variant moet zijn hoe de inzet van events bijdraagt aan je doelstellingen. Als je bijvoorbeeld maximale ontkoppeling nastreeft, zal het terugverwijzen in thin events naar een producer of derde systeem hiertegen indruisen. Toch zie je dat in veel architecturen beiden ingezet worden en je goed kan beargumenteren dat ze ieder aan de algehele doelstellingen bijdragen.

Geen wederzijdse exclusiviteit

Fat en thin events zijn niet namelijk wederzijds exclusief. Je kan ze prima combineren in één architectuur of zelfs in één patroon. Een goed voorbeeld is het Claim Check patroon (zie illustratie). Dit patroon is van toepassing in een architectuur waarin berichten met grote data-objecten (>1mb) tussen systemen verzonden worden via events. De data worden in een derde systeem (bijvoorbeeld een database of object store) opgeslagen en een referentie naar dit systeem wordt in het event zelf gepubliceerd. Dit om te voorkomen dat de events zo groot worden dat ze tot bijvoorbeeld capaciteitsproblemen in het eventplatform leiden.

Je kan een patroon implementeren waarin berichten die groter zijn dan 1 mb automatisch van een claim check worden voorzien en via thin events worden verzonden. Kleinere berichten worden dan wel nog als fat events verzonden. Een goed voorbeeld van hoe fat en thin events in één architectuur ingezet kunnen worden en dus niet wederzijds exclusief zijn.

Fat events kunnen uiteraard ook aangevuld worden met de inhoud van thin events. Een verwijzing naar het systeem dat de data bevat kan dan als aanvulling in het event worden opgenomen. Een dergelijk patroon zet je wel aan het denken, omdat events juist het ontkoppelen van systemen bevorderen. Dat voordeel doe je teniet door de consumers afhankelijk te maken van de beschikbaarheid van andere systemen/producers.

Conclusie: het hangt ervan af

Het is een wat flauwe conclusie, maar of je het beste voor thin events of fat events kan kiezen hangt van je doelstellingen en architectuur af. Thin events leiden er in een architectuur doorgaans wel toe dat je het voordeel van ontkoppeling enigszins tenietdoet, maar er zijn goede argumenten voor het gebruik ervan. Zo hoeft de inhoud van een thin event niet persé naar de producer van hetzelfde event te verwijzen (ook al is dat meestal wel het geval en creëer je ongeacht wel een directe koppeling met een ander systeem).

Een goed voorbeeld is het Claim Check patroon. Als de data in je events groot is (>1mb) of je de inhoud (sterker) wil afschermen, kan je in dit patroon prima thin events inzetten. Je zal in zo’n architectuur wel o.a. stil moeten staan bij het moment waarop zo’n event verzonden wordt i.v.m. latency of de verwerkingstijd van de data store waar het event naar verwijst.

Kortom, het discussiëren over de inhoud van events hoort bij het overwogen inzetten van events in iedere architectuur.