Jeden zapisovatel, mnoho čtenářů

Do repliky zapisuje jediný proces. Není to omezení kapacity — příjem je levný a rejstřík publikuje jeden proud. Je to způsob, jak se vyhnout celé třídě problémů, které by jinak bylo nutné řešit zámky, verzemi a slučováním.

Vlastnictví feedu

právě jeden poller, lease v Redisu s TTL

Výchozí TTL leasu

900 sekund

Výchozí perioda pollu

600 sekund, nejvýš 20 dávek na tik

Čtenáři

API, UI, exporty a analytika čtou projekci, nikdy repliku přímo

Stav

plánováno (fáze 1: poller s leasem)

Co by dva zapisovatelé rozbili

Dva pollery by závodily o checkpoint a duplikovaly práci. Idempotentní zápis podle ID akce by sice zabránil duplicitám v datech, ale ne plýtvání: každý zbytečný požadavek ubírá z denního rozpočtu 3000 požadavků, který je zároveň stropem rychlosti backfillu.

S jedním zapisovatelem jsou záruky uspořádání triviální. Akce se zapisují v pořadí, ve kterém je zdroj publikoval, a nikdo se nemusí ptát, čí verze checkpointu je ta správná.

Lease s TTL, ne zámek navěky

Vlastnictví je časově omezené. Poller, který zemře, lease neuvolní — ten po TTL prostě vyprší a převezme ho jiný. Tím se systém obejde bez ručního odemykání po incidentu.

Poller, který lease nezíská, končí. Nečeká ve frontě a nezkouší to obcházet; příští tik je za pár minut a nic se mezitím neztratí, protože checkpoint drží pozici.

Škálování je otázka na straně čtenářů

Zátěž roste s dotazy nad projekcí, ne s příjmem. Čtenářů může být libovolně mnoho a přidat je neznamená sáhnout na zápisovou cestu.

Zapínání feedu je navíc stupňovité: nejdřív jen příjem, pak projekce a teprve nakonec čtecí API. Chyba v projekci se tak najde ve chvíli, kdy projekci ještě nikdo nečte.

Kde to v repozitáři žije

• docs/INGESTION.md — invarianty příjmu, jeden vlastník feedu, chování checkpointu
• src/progresus_isir/config.py — TTL leasu, perioda pollu, limity dávek a fáze zapínání
• docs/runbooks/feed-rollout.md — stupňovité zapínání feedu od příjmu po čtecí API

Souvisí

Zpět na sekci Architektura