Dokumentová pipeline je oddělená od příjmu

Příjem a extrakce mají různé nákladové profily a různé nároky na latenci. Když běží v jedné frontě, je celý systém pomalý jako nejhorší sken v dávce — a zpoždění za rejstříkem přestane být měřitelné jako samostatná veličina.

Cíl příjmu

událost zpracovaná do 24 hodin od publikace

Limity zdroje

50 požadavků za minutu, 3000 za den; lokální limiter jen přísnější

Dělba práce

příjem zaznamená, že dokument existuje; pipeline ho zpracuje, až na něj dojde

Stav

plánováno (fáze 1: klient feedu, stažení dokumentů, OCR, extrakce)

Dvě rychlosti, dvě fronty

Příjem je čtení metadat: pořadové ID, spisová značka, typ události, typ dokumentu, odkaz. Je levný a musí držet krok s rejstříkem, protože zpoždění za zdrojem je hlavní provozní ukazatel celého produktu.

Extrakce je stažení PDF, OCR, multimodální vytěžení, validace a u nejistých položek zásah analytika. Trvá řádově déle a u dlouhých příloh může trvat velmi dlouho. Sdílená fronta by z téhle latence udělala latenci příjmu.

Selhání v dokumentech nesmí zastavit sledování rejstříku

• Neúspěšné stažení dokumentu ho nechá ve stavu čekající a opakuje se s omezeným počtem pokusů — příjem tím neblokuje.
• Nejistá nebo selhaná extrakce jde do fronty kontroly, ne zpět do příjmu.
• Obě fronty mají vlastní limity, aby dokumentová část nikdy nespotřebovala denní rozpočet požadavků určený pro sledování feedu.

Zpoždění se měří zvlášť

Každá fronta má vlastní metriku zpoždění. Jediné souhrnné číslo by zamaskovalo přesně ten stav, na kterém záleží: rejstřík sledovaný v reálném čase a přitom rostoucí hromada nezpracovaných dokumentů — nebo naopak.

Zpoždění feedu je proto samostatný ukazatel s vlastním runbookem a vlastním alertem.

Kde to v repozitáři žije

• docs/ARCHITECTURE.md — oddělení příjmu a dokumentové pipeline, komponenty a jejich odpovědnosti
• docs/INGESTION.md — poll smyčka, limity, jaké metriky se sledují
• docs/runbooks/feed-lag.md — co dělat, když zpoždění za rejstříkem roste

Souvisí

Zpět na sekci Architektura