Transakční systémy

Proč transakční systémy vyžadují speciální přístup¶

Transakční systém je jiná kategorie software než CRUD aplikace. Když platba projde napůl — peníze odejdou z účtu, ale nepřijdou na druhý — máte problém, který stojí důvěru zákazníků a pozornost regulátora. Stavíme systémy, kde je konzistence garantovaná na architektonické úrovni, ne na úrovni „snad to vyjde”.

ACID ve světě microservices¶

V monolitu je ACID jednoduchý — databázová transakce. V microservices architektuře, kde jedna business operace prochází přes 3-5 služeb, potřebujete jiný přístup.

Saga Pattern: Distribuovaná transakce jako sekvence lokálních transakcí. Každý krok má kompenzační akci — pokud krok 3 selže, kroky 1 a 2 se kompenzují (rollback). Dva přístupy:

• Orchestrace — Centrální orchestrátor řídí flow. Jednodušší debugging, jasná vizualizace.
• Choreografie — Služby reagují na eventy. Menší coupling, ale těžší debugging.

Volíme podle komplexity a týmové struktury. Pro kritické finanční operace preferujeme orchestraci — explicitní flow, lepší error handling.

Outbox Pattern: Garantované doručení eventů. Transakce zapíše data + event do stejné databáze (atomicky). Poller nebo CDC čte events a posílá do Kafky. Žádná ztráta eventů, žádné duplicity (idempotentní consumery).

Architektura platebního systému¶

┌───────────────────────────────────────────────────────┐
│  GATEWAY LAYER                                         │
│  API Gateway → Auth → Rate Limiting → Routing         │
└──────────────┬────────────────────────────────────────┘
               │
               ▼
┌───────────────────────────────────────────────────────┐
│  ORCHESTRATION LAYER                                   │
│  Transaction Orchestrator (Saga)                      │
│  → Validation → Authorization → Settlement → Notify  │
└──────────────┬────────────────────────────────────────┘
               │
               ▼
┌───────────────────────────────────────────────────────┐
│  DOMAIN SERVICES                                       │
│  Account Service │ Payment Service │ Ledger Service   │
│  Fraud Detection │ Compliance │ Notification          │
└──────────────┬────────────────────────────────────────┘
               │
               ▼
┌───────────────────────────────────────────────────────┐
│  DATA LAYER                                            │
│  PostgreSQL (ACID) │ Redis (cache) │ Kafka (events)  │
│  Audit Log (append-only) │ Archive (cold storage)    │
└───────────────────────────────────────────────────────┘

High Availability & Disaster Recovery¶

Pro finanční systémy je dostupnost non-negotiable. Náš HA/DR design:

• Active-Passive s automatickým failoverem — Standby replika v jiné AZ. Automatická detekce výpadku (health checks každých 5s), failover pod 30s. Synchronní replikace pro RPO = 0.
• Multi-AZ deployment — Služby běží minimálně ve 2 availability zonách. Load balancer automaticky routuje traffic na zdravé instance.
• DR testy — Měsíční automatizované failover drilly. Čtvrtletní full DR test s business stakeholdery. Dokumentované, měřené, reportované.
• Chaos Engineering — Náhodné zabíjení instancí v produkci (controlled). Litmus Chaos nebo Chaos Monkey. Validace, že failover skutečně funguje.

Idempotence a deduplikace¶

V distribuovaném systému se requesty opakují — network timeout, retry logic, queue redelivery. Každý endpoint musí být idempotentní:

• Idempotency key — Klient posílá unique key s každým requestem. Duplicitní request vrátí stejný výsledek bez opakování operace.
• Dedup na úrovni Kafky — Exactly-once semantics s transactional producer.
• At-least-once delivery — Consumery jsou idempotentní, duplicate processing je safe.

Audit Trail a Compliance¶

Regulátor nepotřebuje slyšet „věříme, že to funguje”. Potřebuje data:

• Immutable audit log — Append-only, kryptograficky podepsaný. Kdo, co, kdy, odkud, proč.
• Event Sourcing pro klíčové domény — Stav se počítá z historie eventů. Plná rekonstrukce stavu k libovolnému bodu v čase.
• Retention policies — Konfigurovatelné per regulaci (7 let pro finanční transakce, 10 let pro AML).
• Export pro audit — Strukturované reporty, filtrovatelné, exportovatelné. Audit připravený za hodiny, ne týdny.

Performance pod zátěží¶

Platební systém musí být rychlý i pod zátěží. Naše optimalizace:

• Connection pooling — PgBouncer pro PostgreSQL, connection reuse.
• Prepared statements — Eliminace parse overhead pro opakující se dotazy.
• Indexy a partitioning — Tabulky transakcí partitionované po měsíci. Archivace starých dat bez dopadu na výkon.
• Read repliky — Reporting a analytics jdou na read repliku, ne na primary.
• Caching — Redis pro hot data (account balances, rate limits). Cache invalidation přes Kafka eventy.

Výsledek: 5000+ transakcí/sekundu s konzistentní latencí (P99 < 500ms) na standardní infrastruktuře.

Souvisí s