Výsledky extrakce jsou content-addressed a cachované

Tohle není optimalizace. Je to podmínka, bez které by event sourcing v tomhle produktu nefungoval — protože přehrání logu se vyplatí jen tehdy, když nestojí znovu všechny peníze za OCR a LLM.

Klíč cache

SHA-256 dokumentu plus verze extraktoru

Přehrání projekce

čte cache, nestahuje a nespouští OCR ani LLM

Invalidace

zvýšením verze extraktoru, selektivně podle typu dokumentu

Stav

plánováno (fáze 1: úložiště dokumentů, OCR, extrakce)

Ekonomika opravy

Bez cache by přehrání projekce znamenalo znovu vytěžit každý dokument. U backfillu v rozsahu celého rejstříku je to náklad, který se neschvaluje kvůli jedné opravené interpretaci pole.

Důsledek není, že se opravy zdraží. Důsledek je, že se přestanou dělat: tým odloží opravu chyby v datech na později a data tiše zestárnou do stavu, kterému nikdo nevěří. Levné přehrávání je jediná obrana proti tomuhle scénáři.

Adresování obsahem

Identita dokumentu není URL ani pořadové číslo v řízení, ale hash jeho bajtů. Tentýž dokument stažený znovu — nebo publikovaný ve dvou řízeních — se rozpozná jako už známý a nezpracovává se podruhé.

Zároveň tím zůstává stabilní odkaz, na kterém stojí provenience: hodnota ukazuje na hash a stránku, a ten odkaz přežije i opakované stažení.

Invalidace je záměrná, ne plošná

Klíč cache obsahuje i verzi extraktoru. Nová verze tak zneplatní jen to, co skutečně změnila — typicky jeden typ dokumentu — a zbytek se dál čte z cache.

Plošné vyhození cache je operace s cenou celého backfillu a zachází se s ní podle toho.

Kde to v repozitáři žije

• docs/EXTRACTION.md — stádia pipeline a proč je cache architektonické rozhodnutí
• docs/ARCHITECTURE.md — úložiště, jejich znovupostavitelnost a záložní politika
• docs/runbooks/replay.md — runbook přehrání projekce z logu

Souvisí

Zpět na sekci Architektura