(Každodenní práci s gitem přes Claude Code — commity, PR, záchranné situace — pokrývá tahák Git a GitHub s Claude Code. Tady jde o vrstvu nad tím: víc strojů, jeden projekt.)

Základ: remote jako jediný zdroj pravdy

Nejdřív to, co nedělat: nekopírovat složky přes USB a nedávat repo do složky synchronizované iCloudem, Dropboxem ani OneDrivem. Sync klient nevidí do .git atomicky — přenáší soubory po jednom, uprostřed zápisu, a lock soubory a poloviční objekty umí repozitář rozbít způsobem, který se projeví až za týden. O synchronizaci se má starat git — sync klient mu do toho jen hrabe.

Zbytek je disciplína o dvou příkazech:

git pull --ff-only   # než začnu pracovat
# ... práce, commity ...
git push             # než vstanu od stroje

--ff-only znamená, že pull nikdy potichu nevyrobí merge commit. Když se stroje skutečně rozjedou — na obou vznikly commity — příkaz selže a já to řeším vědomě, místo abych to zjistil z divné historie.

Z toho plyne jediné tvrdé pravidlo: nevstávat od stroje s nepushnutými commity. Commit klidně může být rozpracovaný — na to jsou větve a wip: prefixy. Nepushnutý commit je ale commit, který na druhé stanici neexistuje.

Druhá vrstva: synchronizovat kontext, ne jen kód

Kdyby šlo jen o kód, tenhle článek by skončil o odstavec výš. Jenže s Claude Code žije v repu víc než kód:

• CLAUDE.md — instrukce pro agenta: konvence, strukturu projektu, pravidla workflow
• memory/ — persistentní paměť agenta, obyčejné markdown soubory: rozhodnutí, specifikace sekcí, zpětná vazba, rozdělaná práce
• .claude/settings.json — sdílené hooky (o těch za chvíli)
• tools/ — skripty, které hooky spouštějí

Když se tohle všechno verzuje spolu s kódem, druhá stanice není čistá instalace. Sednu k MacBooku a agent ví, co jsme ve středu rozhodli u Windows desktopu — protože si to přečte ze stejných souborů, které tam napsal.

Jedna podmínka: privátní repo. Paměť agenta obsahuje interní poznámky o projektu, rozhodnutí a jejich zdůvodnění — nic z toho nepatří do veřejného repozitáře.

A jedna výjimka: cesty se synchronizovat nedají. C:\Users\... na Windows není /Users/... na Macu. Per-machine nastavení proto žije v gitignorovaném lokálním configu (.claude/settings.local.json), který generuje init skript — spouští se jednou po clone:

./claude-init.sh   # zapíše lokální cesty, doinstaluje per-machine drobnosti

Dělení je pak jednoduché: verzuje se všechno, co je pro stanice společné (instrukce, paměť, hooky, skripty), gitignoruje se všechno, co je per stroj (lokální cesty, buildy, node_modules).

Automatizace rituálu

Rituál „pull před prací, push po ní" má jednu slabinu: spoléhá na mě. A já si po víkendu nevzpomenu. Claude Code umí spouštět příkazy při událostech session — a dvě události přesně odpovídají oběma koncům rituálu:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [{ "type": "command", "command": "bash tools/sync-pull.sh" }]
      }
    ],
    "Stop": [
      { "hooks": [{ "type": "command", "command": "bash tools/unpushed-check.sh" }] }
    ]
  }
}

SessionStart pullne za mě. Jádro skriptu:

git fetch --prune origin
git merge --ff-only '@{u}'   # tiché, když není co; křičí jen při reálném rozjetí

Stop — konec odpovědi agenta — spočítá nepushnuté commity a připomene se:

n=$(git log --oneline @{u}.. 2>/dev/null | wc -l | tr -d ' ')
[ "$n" != "0" ] && echo "📌 Máš $n nepushnutých commitů — git push, ať je vidí druhý stroj."

Efekt v praxi: otevřu session na MacBooku a repo je aktuální dřív, než napíšu první prompt. A protože settings.json s hooky je sám součástí repa, chová se tak každá stanice automaticky — automatizace se synchronizuje stejnou cestou jako všechno ostatní.

Pasti Mac ↔ Windows

Věci, na které se nepřijde čtením dokumentace, ale až když kousnou.

Konce řádků. Windows git s core.autocrlf=true checkoutuje textové soubory s CRLF — včetně bash skriptů. Jednoduchý skript to přežije; skript s podmínkami a funkcemi spadne na neviditelném \r na konci řádku. A protože skript commitnutý z Windows poběží přes hook i na Macu, je to past s časovaným spuštěním. Oprava jednou provždy, v repu:

# .gitattributes
*.sh text eol=lf

Git identity na novém stroji. První commit na čerstvém MacBooku mi skončil hláškou „Author identity unknown". Nic dramatického, ale patří to do checklistu nové stanice, ne do debugování v půlce práce:

git config --global user.name "Jmeno Prijmeni"
git config --global user.email "mail@example.com"

Smazaná větev na remotu. Feature větev mergnutá a smazaná z druhého stroje: na prvním stroji na ní pořád stojím a git pull skončí chybou „no such ref was fetched". Vypadá to jako konflikt, ale je to jen mrtvá reference:

git fetch --prune            # ukliď reference na smazané remote větve
git checkout main && git pull --ff-only

Sync skript výše proto rozlišuje tři stavy: živý upstream (pullni), větev celá obsažená v origin/main (řekni „přepni na main"), a skutečné rozjetí (jediný případ, kdy má křičet).

Nástroje, které na druhé platformě nejsou. lsof v git-bash na Windows chybí, netstat se zase jinak chová na Macu. Skripty sdílené mezi platformami potřebují guard — command -v lsof >/dev/null || exit 0 — aby chybějící nástroj znamenal tichou degradaci, ne rozbitý hook.

Checklist: nová stanice za deset minut

gh repo clone <user>/<repo>          # 1. mimo iCloud/OneDrive/Dropbox složky!
cd <repo>
git config --global user.name "..."  # 2. identita, pokud je stroj čerstvý
git config --global user.email "..."
./claude-init.sh                     # 3. lokální config, per-machine instalace
npm install                          # 4. závislosti projektu

A pátý krok, který se vyplatí nepřeskočit: ověřovací round-trip. Commit z nové stanice, push, pull na staré — a totéž obráceně. Až projdou oba směry včetně hooků, je stanice plnohodnotná. Já si při něm odchytil jak chybějící identitu, tak CRLF ve skriptech.

Závěr

Nesynchronizuji soubory, synchronizuji pracoviště. Měřítko úspěchu je jednoduché — sednu k druhému stroji, otevřu session a první prompt může znít „pokračujeme". Bez vysvětlování, kde jsme skončili. Git nese kód, repo nese kontext a hooky nesou disciplínu, na kterou bych se sám spolehnout nemohl.

Commity a zprávy

Nejčastější věc, kterou po Claudovi chci. Stačí napsat „commitni to“ a pod kapotou proběhne:

git status                 # co je změněné a co untracked
git diff                   # co se skutečně změnilo
git add build.mjs serve.mjs
git commit -m "fix: dev server nepodával webp z podadresářů"

Zprávu píše podle toho, co se v diffu skutečně změnilo — ne podle mojí představy o tom, co jsem udělal. Co se mi osvědčilo:

• Konvence patří do CLAUDE.md. Jazyk commit zpráv, prefixy typu feat:/fix:, formát — jednou zapsat do instrukcí repozitáře a Claude je dodržuje bez připomínání.
• Selektivní commit funguje spolehlivě. Když mám rozdělaných víc věcí najednou:

commitni jen změny v build.mjs, zbytek nech být

Pod kapotou je to git add build.mjs a commit — žádné git add -A, které by s sebou vzalo i rozpracovaný zbytek.

• Nesouvisející změny nechám rozdělit. „Rozděl to do logických commitů“ — Claude si projde diff, seskupí soubory podle toho, co k čemu patří, a stageuje po skupinách (v krajním případě po hunkách přes git add -p).

Co si hlídám: push je vždycky explicitní krok. Claude mám instruovaný, ať nikdy nepushuje sám — commit je lokální a vratný, push už je publikace.

Zpátečka: amend, restore, stash

Drobné opravy, na které jsem dřív hledal přesný příkaz na Stack Overflow:

• „Přidej tohle do posledního commitu“:

git add build.mjs
git commit --amend --no-edit

Amend přepisuje historii — bezpečný je jen do chvíle, než commit pushnu. Claude na to upozorní sám, ale je dobré to vědět.

• „Zahoď změny v serve.mjs“:

git restore serve.mjs            # zahodí neuložené změny v souboru
git restore --staged serve.mjs   # jen vyndá ze stage, změny nechá

• „Ulož rozdělanou práci, potřebuju hotfix“:

git stash push -m "wip: nova paticka"
git stash list
git stash pop

Jen pozor: když git stash pop narazí na konflikt, změny aplikuje, ale stash nesmaže — schválně, ať o nic nepřijdete. Po vyřešení konfliktu ho ukliďte ručně: git stash drop.

Od té doby, co používám worktrees, stashuju míň — viz další sekce.

Větve a worktrees

Založení větve je jednoduché — „založ větev pro úpravu patičky“:

git switch -c feat/paticka

Zajímavější jsou worktrees: druhá pracovní kopie repozitáře na jiné větvi, ve vedlejším adresáři.

git worktree add ../projekt-oprava fix/prepocet-provizi
git worktree list
git worktree remove ../projekt-oprava   # až je hotovo

K čemu je to dobré s AI nástrojem: můžu mít dvě session Claude Code vedle sebe — jedna píše novou feature, druhá opravuje bug — a nešlapou si po souborech, protože každá pracuje ve vlastním adresáři. Bez přepínání větví a bez git stash akrobacie.

Dvě věci, které worktree nováčkovi neřekne: stejnou větev nejde mít checkoutnutou ve dvou worktrees najednou (git to odmítne — a dobře dělá). A node_modules se neklonují: každá kopie si žije vlastním životem, takže po git worktree add přijde ještě npm install.

(Worktrees řeší paralelní práci na jednom stroji. Jak udržet jeden projekt — včetně kontextu Claude Code — synchronizovaný mezi dvěma počítači, popisuje Jedno repo, dvě klávesnice.)

Pull requesty přes gh CLI

Claude Code používá GitHub přes oficiální gh CLI. Jednorázová příprava:

brew install gh            # macOS
winget install GitHub.cli  # Windows
sudo apt install gh        # Debian/Ubuntu
gh auth login              # jednorázové přihlášení

Pak stačí:

vytvoř PR proti main, popis stručně

Pod kapotou:

git log main..HEAD --oneline   # jaké commity větev přináší
git diff main...HEAD           # celý diff větve proti main
git push -u origin feat/paticka
gh pr create --base main --title "..." --body "..."

Popis PR vzniká ze skutečného diffu celé větve proti main, ne jen z posledního commitu — takže sedí i po deseti commitech s opravami. Druhý směr funguje taky:

načti review komentáře z PR #42 a zapracuj je

gh pr view 42 --comments                        # diskuze pod PR
gh api repos/{owner}/{repo}/pulls/42/comments   # inline komentáře v kódu

Claude si komentáře stáhne, projde je jeden po druhém a ke každému řekne, co s ním udělal. U komentářů, se kterými nesouhlasí, chci, aby to řekl — ne aby slepě vyhověl.

Review cizího PR — „stáhni PR #42 a projdi ho“:

gh pr checkout 42   # větev PR do lokální kopie
gh pr diff 42       # rychlý pohled bez checkoutu

A merge, když je hotovo — „mergni PR #42 squashem“:

gh pr merge 42 --squash --delete-branch

Merge beru stejně jako push: je to publikace, tak ho odklepávám explicitně.

Issues a CI

Sekce, kterou jsem v první verzi tohohle taháku vynechal — a přitom je to půlka toho, co gh denně dělá.

• „Vypiš otevřené issues s labelem bug“:

gh issue list --label bug --state open
gh issue view 12

• „Založ z tohohle issue“ — uprostřed session, když narazím na bug, který teď nechci řešit:

gh issue create --title "..." --body "..." --label bug

Popis píše Claude z kontextu session, dokud je čerstvý — takže je konkrétní: co se stalo, kde, jak to reprodukovat. Issue založené takhle je použitelnější než to, které bych psal z hlavy o tři dny později.

• „Proč spadla CI na téhle větvi?“ — možná největší časová úspora z celého taháku:

gh pr checks                        # stav checků na PR
gh run list --branch feat/paticka   # poslední běhy workflow
gh run view 1234567890 --log-failed # log jen toho, co selhalo

Claude si vytáhne log selhání, najde příčinu a rovnou navrhne opravu. Bez klikání do webového UI a scrollování kilometrovým logem.

Review vlastního diffu před PR

Než PR otevřu, nechám si diff projít ještě lokálně — je to levnější než pálit čas kolegy:

zreviduj diff téhle větve proti main — hledej chyby a rizika, ne styl

git diff main...HEAD

Tři tečky nejsou překlep: diff proti společnému předku (merge-base) ukáže jen to, co přinesla moje větev — ne změny, které mezitím přistály v main.

Funguje tím líp, čím konkrétnější zadání dostane: „zaměř se na ošetření chyb“, „hledej race conditions“, „zkontroluj, že se nikde neloguje osobní údaj“. Obecné „mrkni na to“ vrací obecné odpovědi.

Záchranné situace

Tady se pozná, jestli vám AI pomáhá, nebo škodí.

• Konflikty při merge/rebase — Claude je vyřeší, ale chci vidět zdůvodnění:

vyřeš konflikty; u každého souboru mi řekni, kterou stranu jsi vzal a proč

git status                        # které soubory jsou v konfliktu
git checkout --ours soubor.js     # vzít celou naši stranu
git checkout --theirs soubor.js   # vzít celou jejich stranu
git rebase --abort                # nouzová brzda: vrátit vše před rebase

Většinou ale Claude konfliktní bloky edituje ručně — je to přesnější než brát celé soubory jednou stranou. (A pozor na klasickou past: při rebase se význam --ours/--theirs otáčí.)

• Revert — bezpečná operace, vytváří nový commit, nic nepřepisuje:

git revert abc123

• Bisect — hledání commitu, který něco rozbil, je s AI konečně bezbolestné:

najdi bisectem commit, který rozbil build; testuj příkazem node build.mjs

git bisect start
git bisect bad                  # HEAD je rozbitý
git bisect good v1.4            # tady to ještě fungovalo
git bisect run node build.mjs   # automatický test každého kroku
git bisect reset

S git bisect run proběhne celé půlení bez jediného ručního kroku — Claude jen odečte výsledek a ukáže viníka.

• Reflog — poslední záchrana, když „tu včera byl commit a teď je pryč“:

git reflog                    # deník všeho, kde HEAD kdy byl
git reset --hard HEAD@{2}     # návrat na konkrétní stav

Čtení reflogu je bezpečné. Ten reset --hard na konci už ne — a tím jsme u pointy: git reset --hard, force push a mazání větví si dělám ručně, nebo minimálně chci, aby se Claude před provedením explicitně zeptal. Nastavení oprávnění v Claude Code tomu jde naproti: destruktivní příkazy nechávám na ručním schválení.

Rychlá reference

Závěr

Gitu kvůli Claudovi nepřestávám rozumět — právě naopak, bez toho bych nepoznal, kdy sáhne vedle. Jen už nemusím ručně psát příkazy, které umím nadiktovat, a ušetřenou energii dávám do kontroly výsledků. Git zůstává stejný, jen na klávesnici píše někdo jiný.

Proč PoC vypadá hotově za týden

U proof of conceptu se snadno zapomíná na jednu věc: předvádí se na scénářích, které si vybral jeho autor. Deset ukázkových případů projde hladce, publikum je nadšené a všem se zdá, že zbývá „jen to nasadit“.

Jenže PoC většinou běží na vybraných datech, bez reálných oprávnění, bez auditní stopy a s člověkem, který u toho sedí a drobné přešlapy tiše opravuje. Nic z toho v produkci mít nebudete. PoC odpovídá na otázku „umí to fungovat?“ — produkce se ptá, co se stane, když to fungovat přestane.

Jak ten rozdíl vypadá v praxi, ukázala Klarna. V únoru 2024 oznámila, že její AI asistent zvládl za první měsíc dvě třetiny zákaznické podpory — „práci 700 lidí“. O rok později CEO přiznal, že škrty přes AI zašly moc daleko, kvalita šla dolů a firma zase nabírá lidi. Tisková zpráva měřila, kolik konverzací agent vyřídil. Jak dobře — to se řešilo až o rok později.

Co přidává enterprise

V regulovaném prostředí přibývají požadavky, které demo nikdy řešit nemuselo:

• Auditní stopa. Každé rozhodnutí agenta musí být dohledatelné: co viděl na vstupu, proč a jak rozhodl, co provedl. „Model to tak vyhodnotil“ auditorovi ani regulátorovi stačit nebude.
• Odpovědnost. Když agent udělá chybu, musí být předem jasné, kdo za ni odpovídá a jak se opraví. Je to procesní otázka — a odpověď na ni chcete mít dřív, než agenta pustíte do produkce, ne až po prvním průšvihu. Soudy už na to názor mají: kanadský tribunál v únoru 2024 nechal Air Canada zaplatit za slevu, kterou si její chatbot vymyslel. Aerolinka se hájila tím, že chatbot je „samostatná právní entita odpovědná za své vlastní jednání“ — tribunál to označil za pozoruhodné tvrzení a nárok uznal. Šlo o 812 kanadských dolarů, ale ten případ se od té doby cituje jako precedens: za výstupy chatbota odpovídá firma.
• Data governance. V PoC je pohodlné pustit agenta ke všemu. V produkci musí přístup k datům odpovídat účelu — agent na likvidaci pojistných událostí nemá co číst mzdové údaje, i kdyby mu to zlepšilo odpovědi.
• Bezpečnost. Agent je nová útočná plocha: vstupy, kterým věří, se dají podvrhnout (prompt injection je jen ten nejznámější případ), a čím víc akcí smí provést, tím víc škody podvržený vstup napáchá. Dlouho se to ilustrovalo hlavně na kuriozitách, jako byl chatbot dealera slibující Chevrolet Tahoe za dolar. Pak ale v červnu 2025 vyšel EchoLeak: první zero-click prompt injection na produkčního enterprise agenta (Microsoft 365 Copilot, CVSS 9.3). Stačil jeden obyčejně vypadající e-mail v poště — agent si ho sám zatáhl do kontextu a citlivá data odtekla, aniž by uživatel na cokoli klikl. Naštěstí to našli bezpečnostní výzkumníci.

A nejde jen o interní opatrnost. Podle EU AI Act spadá AI pro risk assessment a pricing v životním a zdravotním pojištění rovnou mezi high-risk systémy, s povinnostmi od srpna 2026 (v Bruselu se řeší odklad, ale směr platí). Takže velká část těch odrážek nahoře bude dřív nebo později prostě povinnost ze zákona.

Kde smí agent jednat sám

Nejdůležitější návrhové rozhodnutí celého řešení: které akce smí agent udělat sám a kde musí být člověk ve smyčce. Používám na to jednoduchou mřížku — dvě osy, vratnost a dopad:

• Vratné + malý dopad → agent jedná sám (návrh odpovědi, kategorizace, příprava podkladů).
• Vratné + velký dopad → agent jedná, člověk kontroluje vzorky a metriky.
• Nevratné + malý dopad → agent připraví, člověk potvrdí jedním klikem.
• Nevratné + velký dopad → agent pouze doporučuje; rozhoduje člověk (výplata pojistného plnění, výpověď smlouvy).

Ta hranice navíc není daná jednou provždy. Vyplatí se začít konzervativně a pravomoci agentovi přidávat podle toho, co ukážou čísla z provozu — vyjde to levněji než začít zostra a po prvním incidentu všechno zase zamknout.

Agent jako nový účastník procesu

K agentovi se často přistupuje jako k dalšímu systému, který se prostě „zintegruje“. Mně v praxi víc pomáhá představa nového kolegy: rychlého, co se nikdy nenudí, ale občas si zadání vyloží po svém.

Z té představy plynou praktické otázky, které byste u nového kolegy položili taky: kdo mu zadává práci a v jakém formátu? Komu předává výsledek? Jak pozná, že si neví rady, a komu to řekne? A co se stane s procesem, když zrovna „nepřijde do práce“? Proces, který na tyhle otázky nemá odpověď, na agenta připravený není — bez ohledu na to, jak dobrý ten agent je.

Co měřit, aby šlo říct „funguje to“

Bez metrik se debata o agentovi vede na anekdotách: jeden si pamatuje skvělou odpověď, druhý průšvih. Tohle je minimální sada, kterou chci mít od prvního dne:

1. Úspěšnost na konci procesu — ne „agent odpověděl“, ale „případ byl správně vyřízen“, měřeno stejným metrem jako u lidí. Přesně na tomhle skončila AI v drive-thru McDonald’s: dva roky testů ve víc než stovce restaurací, jenže přesnost objednávek se podle franšízantů držela kolem 80 % a cíl byl 95. To virální video s 260 nugety v jedné objednávce byl jen ten nejviditelnější projev.
2. Míra eskalací — jak často agent předává práci člověku. Nízké číslo nemusí být dobrá zpráva: agent, který nikdy neeskaluje, spíš nepozná, kdy si neví rady.
3. Cena za vyřízený případ — včetně nákladů na kontrolu a opravy po agentovi. Bez nich vám vyjde hezčí číslo, než jaká je realita.
4. Trend oprav — kolik agentových výstupů museli lidé předělat a jak se to vyvíjí. Podle tohohle čísla se posouvá hranice samostatnosti z předchozí kapitoly.

Závěr

Nasadit AI agenta do enterprise znamená hlavně rozhodnout, kolik důvěry mu dáte: co smí udělat sám, kdo za něj odpovídá a čím se měří, že funguje. Technologie je dnes připravenější, než většina organizací tuší. Co obvykle chybí, jsou procesy, odpovědnosti a metriky.

Kdo potřebuje odpověď a kdy

Otázka, která architektura je „lepší“, se rozhodnout nedá. Užitečnější je ptát se, kdo potřebuje odpověď a kdy: když volající bez výsledku nemůže pokračovat, potřebujete synchronní volání; když ho výsledek zajímá „až to bude“, nebo zajímá víc příjemců, jste na území eventů. Většina sporů skončí ve chvíli, kdy se přestane mluvit o technologii a začne o procesu.

Kdy synchronní API

Synchronní volání je správná volba, když:

• Volající bez odpovědi nemůže pokračovat. Ověření limitu před potvrzením obchodu, výpočet ceny v kalkulaci, kontrola oprávnění. Čekání tady k operaci prostě patří.
• Chybu chcete řešit hned a v kontextu. Synchronní volání vrátí chybu tomu, kdo se ptal, ve chvíli, kdy se ptal — a ten může hned reagovat: opravit vstup, zkusit to znovu, říct to uživateli.
• Tok má být čitelný. Řetěz synchronních volání se čte shora dolů a pořadí kroků z něj vidíte na první pohled. U procesů, kde na pořadí a srozumitelnosti záleží, to má velkou cenu.

Cena, kterou za to platíte: provázaná dostupnost. Každý článek synchronního řetězu dědí výpadky všech ostatních. Deset služeb s dostupností 99,9 % za sebou dá dohromady 0,999¹⁰ ≈ 99,0 % — z devíti hodin výpadku ročně je najednou osmdesát sedm. A tempo všem určuje ten nejpomalejší.

A pak je tu retry storm: malý výpadek se vlnou opakovaných volání nafoukne do velkého. Přesně tohle se stalo při výpadku DynamoDB v září 2015 — síť se vzpamatovala za okamžik, jenže vlna synchronních retry pak držela metadata službu přetíženou skoro pět hodin a kaskáda s sebou vzala SQS, CloudWatch i autoscaling. O délce výpadku tedy nerozhodla síť, ale architektura okolo ní. A v říjnu 2025 se to samé zopakovalo ve stejném regionu, tentokrát na čtrnáct hodin.

Kdy eventy

Event je správná volba, když:

• Výsledek zajímá víc odběratelů. Uzavřená smlouva zajímá provize, reporting, dokumenty i marketing. Publikovat jeden event je lepší než volat čtyři API — a pátý odběratel se příště přidá, aniž byste sahali do zdroje.
• Producent nemá znát své konzumenty. Event říká „stalo se“, ne „udělej“. Zdrojový systém se nemusí měnit pokaždé, když si výsledek chce odebírat někdo nový. To je na event-driven přístupu to hlavní: životní cykly systémů se od sebe odpojí.
• Špičky zátěže nemají procházet dál. Fronta mezi producentem a konzumentem nápor rozloží v čase, místo aby se valil kaskádou do dalších systémů.
• Proces snese asynchronnost. „Do několika sekund“ většině navazujících kroků stačí — jen to byznys musí vědět a odsouhlasit.

Cena je tentokrát provozní a mentální: eventy se hůř ladí. Tok procesu nevidíte v jednom trace, konzistence je eventuální, objeví se duplicitní doručení a mrtvé zprávy (DLQ). Bez pořádného monitoringu a idempotentních konzumentů se z „moderní architektury“ stane systém, kterému nikdo nerozumí.

K duplicitám jedna věc, kterou je lepší vědět předem: at-least-once doručení je součást kontraktu. SQS i Stripe webhooky to píšou přímo v dokumentaci — občas prostě dorazí ta samá zpráva dvakrát. Konzument, který na druhé doručení odpoví druhou výplatou provize, má chybu v návrhu; s duplicitami měl počítat. Řešení je staré a osvědčené: idempotency key — stejný požadavek se stejným klíčem se provede jen jednou, ať dorazí kolikrát chce.

Šedá zóna a hybridy

Reálný svět málokdy zapadne čistě do jedné škatulky:

• Request-reply přes eventy — volající pošle požadavek do fronty a čeká na odpovědní event. Špičky se vám rozloží v čase, ale zaplatíte za to složitější korelací. Dává smysl u dlouhých operací, ne jako náhrada obyčejného volání.
• Outbox pattern — když potřebujete zapsat do vlastní databáze a zároveň spolehlivě publikovat event, zapište obojí v jedné transakci (event do outbox tabulky) a publikování nechte na samostatném procesu. Řeší klasický problém „zapsáno, ale neodesláno“.
• Synchronní čtení, asynchronní zápis — častý a zdravý kompromis: na aktuální stav se ptáte přes API, změny se rozhlašují eventy.

Cena každé volby

Žádná z možností není zadarmo — liší se jen tím, kde a kdy zaplatíte:

Závěr

Celý rámec se vejde do tří otázek: kdo potřebuje odpověď a kdy, kolik je odběratelů a co se má stát při výpadku. Odpověď na „API, nebo event?“ z nich většinou vypadne sama. A když si dvě části procesu řeknou každá o něco jiného, nic se neděje — každá prostě potřebuje něco jiného.