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.

%% title: Cesta údaje od rejstříku k analytikovi
%% caption: Příjem metadat a zpracování dokumentů běží ve dvou oddělených frontách. Do projekce se zapíše jen hodnota, která prošla validací a prahem spolehlivosti; ostatní jde k člověku. Schéma popisuje návrh, stav po oblastech drží roadmapa.
flowchart LR
  subgraph SRC["Zdroj"]
    WS[("WS ISIR<br/>proud akcí")]
  end
  subgraph ING["Příjem"]
    POL["Poller<br/>jeden zapisovatel"] --> REP[("Replika<br/>append-only log")]
  end
  subgraph DOC["Dokumentová pipeline"]
    DL["Stažení PDF"] --> EX["OCR + LLM<br/>extrakce do schématu"] --> VAL{"Validace<br/>a práh"}
  end
  subgraph OUT["Čtení"]
    PRJ[("Projekce<br/>odvozená")] --> API["Čtecí API<br/>a aplikace"]
  end
  WS --> POL
  REP -- "akce s dokumentem" --> DL
  REP --> PRJ
  VAL -- "jisté" --> PRJ
  VAL -- "nejisté" --> Q["Fronta<br/>lidské kontroly"]
  Q -- "rozhodnutí je událost" --> PRJ
  click WS href "/docs/semantika-zdroje" "Sémantika zdroje ISIR"
  click POL href "/architecture/jeden-zapisovatel-mnoho-ctenaru" "Jeden zapisovatel, mnoho čtenářů"
  click REP href "/architecture/event-sourcing-protoze-zdroj-je-event-stream" "Event sourcing"
  click DL href "/architecture/oddelena-dokumentova-pipeline" "Oddělená dokumentová pipeline"
  click EX href "/architecture/ocr-a-llm-extrakce-do-schematu" "OCR + LLM extrakce do schématu"
  click VAL href "/architecture/confidence-je-plnohodnotne-pole" "Confidence je plnohodnotné pole"
  click Q href "/roadmap/fronta-lidske-kontroly" "Fronta lidské kontroly"
  click PRJ href "/about/log-je-pravda-projekce-je-odvozena" "Log je pravda, projekce je odvozená"
  click API href "/api" "Přehled API"
  class Q st-in_progress

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