Mozno som s tym event sourcingom uz trapny, ale podla mna toto je ucebnicovy priklad
, ktory by bol jednak este vykonnejsi, horizontalne skalovatelny s mnozstvom dalsich vyhod.
Eventy by boli nieco ako:
- RegistrationRequested, ktore by sa zapisovali bez validacie a potom spracovavane nejakym background workerom, ktory by produkoval:
- RegistrationConfirmed.
Alternativne, RegistrationRequested by nemusel byt event, ale command, to znamena ze by sa neperzistoval.
Read cast by potom mohol byt obycajny in-memory dictionary, alebo cokolvek co sa ti hodi a malo by to byt radovo rychlejsie ako in memory SQL
Trik je v tom, ze read cast si vies jednak denormalizovat a optimalizovat a druhak nemas problem si vytvorit tolko replik, kolko sa ti zapaci.
Event Store je append only, to znamena ze vies do neho velmi rychlo zapisovat a aj z neho velmi rychlo citat, kedze data sa nemenia a vies ho aj jednoducho replikovat (kedze data sa nemenia).
Navyse, v tomto pripade by sa dala horizontalne skalovat nielen read cast, ale aj write cast. V tvojom pripade by mohol byt DistributionKey PlaceId. Na to aby si zistil, ci je nejake miesto obsadene, potrebujes eventy len z toho jedneho miesta, takze kadze miesto by mohlo byt obsluhovane osobitnym nodom, ale neverim ze by si vytazit co i len jeden server.
Mimochodom, vedel by si zakomponovať do tvojho testu aj nejake rezervacie. Napr kazdy 5 request by bol POST a nie GET?