Fronta zpráv

Úlohu vyndejte z požadavku, když trvá víc než sekundu, může se ztratit, aniž by si toho uživatel všiml, nebo závisí na externí službě, která občas padá. API vrátí 202 Accepted a id úlohy; frontend pak sleduje stav přes endpoint nebo realtime. Zákazník dostane potvrzení za 200 ms a e-mail s fakturou odejde, jakmile mailserver dovolí.

U AI úloh je to skoro povinnost. Generování nebo shrnutí, které trvá minutu, nesmí držet HTTP spojení — dejte ho do fronty, zpracujte a výsledek uložte pod id úlohy.

Selhání jsou normální: mailserver zprávu odmítne, AI poskytovatel vrátí 529, služba na PDF restartuje. Zkuste to párkrát s exponenciálně rostoucí prodlevou a stropem — maximálně pět pokusů — a pak skončete. Zpráva, která pořád selhává, nesmí blokovat frontu za sebou na další dvě hodiny.

Po vyčerpání pokusů jde zpráva do dead-letter fronty, kde rozbité zprávy čekají na člověka. Nastavte alarm na jejich počet, protože dead-letter fronta, kterou nikdo nesleduje, je jen hodně pomalá ztráta dat.

Kafka první den nepotřebujete. Tabulka úloh v PostgreSQL se sloupcem stavu, zámkem a smyčkou workera zvládne tisíce úloh denně bez nové infrastruktury a čekající práci máte na jeden SELECT. Na samostatný broker přejděte, až když potřebujete fan-out, garantované pořadí nebo statisíce zpráv.

Každý handler ale i tak musí být idempotentní: doručení aspoň jednou znamená, že zpráva může projít dvakrát, třeba po timeoutu, když worker práci ve skutečnosti dokončil. Upřímný kompromis je pozorovatelnost — úloha ve frontě je z pohledu stack trace neviditelná. Logujte id úlohy v každém kroku, dejte hloubku fronty a chybovost do dashboardu a přidejte admin stránku pro opětovné spuštění neúspěšných úloh.