De laatste tijd moet ik vaak de discussie voeren waarom traditioneel silo-based synchrone ontwerpen niet geschikt zijn voor schaalbare systemen.  Een systeem wordt schaalbaar genoemd als elke verdubbeling van de infrastructuur voor een gelijkaardige toename van het aantal parallelle requests zorgt, zonder verlies van performantie. Dit klinkt niet zo uitdagend? Dit kunnen we op de standaard manier bekomen?

Tijd dan voor een denkoefening: we gaan de klassieke manier van ontwerpen toepassen op de werking van een McDonalds restaurant…

Synchrone verwerking

Bij McDonalds is de verwerking van de bestellingen ontkoppeld van het vervaardigen van de hamburgers.  Beeld u in dat een verkoper verantwoordelijk zou zijn voor de hele (verticale) keten.   Hij zou de bestelling opnemen, de hamburger klaarmaken,de afrekening geven en slechts dan de volgende klant bedienen.  Als deze handeling 5 minuten duurt, kun je met één verkoper 12 klanten kunnen bedienen per uur.

Hij zou niet weten dat de volgende bestelling identiek zou zijn.. Hij zou voortdurend van context moeten veranderen (handen wassen), geld in ontvangst nemen.   Ook zou er erg moeilijk samengewerkt kunnen worden tussen de verschillende verkopers. Niet echt efficiënt dus.

 

Geen concurrency control (volledige parallellisatie)

Wat als je 24 klanten per uur wil bedienen? Per veelvoud van 12 moet er een extra verkoper aangeworven worden.  En wat als op een bepaald moment  deze 12 klanten tegelijk zouden aankomen?  De 12de zou een uur moeten wachten…

Maar wacht — deze verkoper kan misschien wel verschillende bestellingen tegelijk aannemen? (cf. multithreading) In het extreme geval wordt elke nieuwe bestelling meteen door een verkoper behandeld.  Hij is dan tegelijk bezig met het afhandelen van een betaling, het maken van een paar hamburgers, het opnemen van enkele bestellingen.  Iedereen ziet wel in dat de efficiëntie van deze verkoper drastisch zal dalen door deze “parallellisatie” –– hij beschikt immers slechts over beperkte resources (kan bv. maar N woorden per minuut schrijven – I/O)

Het is duidelijk dat er een optimale trade-off moet gevonden worden tussen de hoeveelheid parallellisatie (# tegelijk behandelde requests door een machine) en de grootte van de wachtrijen.  Stel dan nog dat je “oneindig” veel verkopers kunt aannemen… Op een bepaald moment is er een plaatsgebrek, niet?  Het evenwicht bevindt zich typisch niet aan een van de extremen en hangt af van de bezoekpatronen van de McDanolds —  misschien komen er nooit 12 mensen tegelijk aan?

 

Centraal register met recepten (centrale database)

Omwille de kwaliteit te garanderen, stelt de chef-kok een centraal register op waarin beschreven staat hoe elke hamburger bereid moet worden.  Omdat de chef zeker wil zijn dat de juiste recepten gevolgd worden, is het een verplichting  om het register steeds te raadplegen voor het klaarmaken van een hamburger.  5 verkopers kunnen wel samen lezen, maar als de chef een wijziging aanbrengt, is het register niet meer zichtbaar.

Wat als er 50 verkopers een recept willen lezen? Of wat als er heel vaak wijzigingen gebeuren?  Hoeveel verkopers er ook aangeworven worden, de bottleneck bevindt zich op het centraal register.  En wat als iemand het register per ongeluk onleesbaar maakt?

 

Caching aan het eind van de keten

Een ingrediënt voor een bepaald type hamburger is niet meer in stock.  Het is dus onmogelijk om deze hamburger te bereiden.   Omdat de verkoper echter geen korte-termijn geheugen heeft (geen cache), moet hij telkens het recept gaan opzoeken in het centraal register.  Hier haalt hij de ingrediënten op en vraagt of ze nog beschikbaar zijn.  Niet dus — de verkoper loopt terug naar de klant en brengt het spijtige nieuws. Hij loopt onnodig heen, en weer.

 

Bottom line

Het is belangrijk om bepaalde ontwerp-reflexen in vraag te stellen. Vaak zijn het dogma’s die niet universeel geldig zijn en een serieuze performantie, beschikbaarheid en schaalbaarheidsimpact hebben.