Core Information Systems

Logistika je real-time byznys. Zásilka, která se ztratí v systému na 5 minut, způsobí kaskádu problémů — špatné třídění, zpoždění doručení, SLA pokuty. Stavíme WMS a logistické IS, kde každá zásilka má v každém okamžiku jasný stav a jasnou cestu.

Event-driven architektura je základ. Každý scan, každé přetřídění, každé naložení generuje event do Apache Kafka. Downstream systémy (tracking, billing, reporting) konzumují eventy nezávisle. Výpadek jednoho systému nezastaví třídění — eventy čekají v Kafce a zpracují se po obnovení.

Throughput a latence: Naše WMS systémy zpracovávají 10 000+ zásilek/hodinu v jednom depu. API latence pod 50ms na P95. Horizontální škálování přes Kubernetes — přidání kapacity za minuty, ne dny. Load testing s k6 simuluje vánoční špičky měsíce předem.

Integrace s hardware: Třídící linky, skenovací brány, váhy, tiskárny štítků. Komunikujeme přes OPC-UA, REST API i proprietární protokoly. Edge processing na zařízení zajistí funkčnost i při výpadku sítě — data se synchronizují po obnovení konektivity.

Příklad z praxe: Pro logistickou firmu s 15 depy jsme nahradili monolitický systém event-driven architekturou. Výsledek: throughput 3× vyšší, MTTR z hodin na minuty, nulové ztráty zásilek v systému. ROI za 8 měsíců.

Transakční systém nemá prostor pro „skoro funguje”. Když platba projde napůl, máte problém. Stavíme systémy s ACID garanty, kde každá transakce je buď kompletní, nebo se neudělala vůbec. Žádné nekonzistentní stavy, žádné ztracené peníze.

Architektura pro spolehlivost: Saga pattern pro distribuované transakce přes více služeb. Outbox pattern pro garantované doručení eventů. Idempotentní API — opakovaný request nezpůsobí duplicitní transakci. Dead letter queue pro failed messages s automatickým retry a alertingem.

HA/DR design: Active-passive s automatickým failoverem (RTO < 30s). Synchronní replikace pro zero data loss (RPO = 0). Pravidelné DR testy — ne jednou ročně na papíře, ale automatizované měsíční failover drill. Georedundance pro kritické systémy.

Audit a compliance: Každá transakce logovaná s plným kontextem — kdo, co, kdy, odkud. Immutable audit log (append-only). Regulátor dostane kompletní trail za minuty, ne dny. Kompatibilní s požadavky ČNB, PSD2, DORA.

Výkon pod zátěží: Zpracováváme tisíce transakcí/sekundu s konzistentní latencí. Connection pooling, prepared statements, optimalizované indexy. Load testing simuluje Black Friday 2× dopředu — víme, kde je limit, dřív než ho zasáhneme.

Věrnostní program je core systém, ne marketingový gadget. Když zákazník zaplatí a body se nepřipíšou do 5 sekund, volá na zákaznickou linku. Když partner nemá aktuální data, odmítne slevu. Stavíme loyalty platformy, které zvládají miliony zákazníků v reálném čase.

Real-time processing: Body se připisují v okamžiku transakce, ne v nočním batchi. Event-driven architektura — POS systém pošle event, loyalty engine zpracuje pravidla (multipliers, bonus akce, tier upgrady), zákazník vidí aktualizovaný stav okamžitě. Latence < 200ms end-to-end.

Rules engine: Flexibilní pravidla bez deploye — marketingový tým nastaví kampaň (2× body na víkend, bonus za nákup nad 1000 Kč, partner multiplier), systém ji aplikuje okamžitě. Verzování pravidel, A/B testing kampaní, real-time reporting výkonu.

Partnerská integrace: REST API pro partnery s OAuth2, rate limiting, webhook notifikace. Partner dotáže stav bodů, uplatní slevu, reportuje transakci. SLA per partner, monitoring per endpoint. Typicky 10-50 partnerů, každý s vlastními pravidly.

Škálování: Miliony zákazníků, desítky milionů transakcí měsíčně. Redis pro hot data (aktuální body, tier), PostgreSQL pro historii. Horizontální škálování — přidání nového partnera nezpomalí existující. GDPR compliance — právo na výmaz, portabilita dat, consent management.

Big-bang rewrite je sázka, ne strategie. 70% velkých rewrite projektů selže nebo překročí budget 2×+. Modernizujeme postupně — strangler fig pattern, kde nový systém postupně přebírá funkce starého. Každý krok je deploynutelný, testovatelný a rollbackovatelný.

Náš 7-krokový playbook: (1) Stabilizace — monitoring, metriky, baseline. (2) Domain mapping — event storming, bounded contexts, dependency analýza. (3) API gateway — fasáda před legacy, routing pravidla. (4) Izolace prvního modulu — nejmenší bounded context s nejmenšími závislostmi. (5) Data migrace — CDC (Change Data Capture), dual-write, reconciliation. (6) Postupný rollout — canary releases, traffic shifting 5% → 25% → 50% → 100%. (7) Decommission — starý modul off, monitoring nového.

Data migrace je nejtěžší část. Legacy systémy mají roky accumulated technical debt v datech — nekonzistentní formáty, chybějící validace, duplicity. Používáme CDC (Debezium) pro real-time replikaci, reconciliation joby pro ověření konzistence, a rollback plán pro každý krok.

Řízení rizika: Každý krok modernizace má definované metriky úspěchu, rollback plán a komunikační protokol. Feature flags oddělují deploy od release — kód je v produkci, ale funkce je vypnutá, dokud neprojde validace. Nikdy neměníme víc než jeden modul naráz.

Reálné výsledky: Typická modernizace trvá 6-18 měsíců (závisí na velikosti). Přináší hodnotu od prvního kvartálu — lepší monitoring, rychlejší deploye, snížené provozní náklady. Celkový TCO typicky klesne o 30-50% díky eliminaci legacy maintenance.

Microservices bez DDD jsou distribuovaný monolith. Rozdělení na služby podle technických vrstev (auth service, notification service) místo podle domén vede k těsné provázanosti, distributed transactions a deployovacímu peklu. DDD definuje hranice služeb podle business domén — každý bounded context má jasnou odpovědnost.

Event Storming jako discovery nástroj: Než napíšeme řádek kódu, děláme Event Storming s domain experty. 2-3 dny workshopů, kde zmapujeme business procesy, identifikujeme agregáty, bounded contexts a doménové eventy. Výstup: mapa systému, kterou rozumí business i technici.

Event Sourcing & CQRS: Pro domény, kde potřebujete kompletní historii (finance, audit, compliance), používáme Event Sourcing — stav se počítá z historie eventů, ne z posledního snapshotu. CQRS odděluje čtení od zápisu — read model optimalizovaný na dotazy, write model na business logiku.

Organizační škálování: Conway’s Law říká, že architektura kopíruje organizaci. S DDD to otočíme — bounded contexts definují optimální týmovou strukturu. Každý tým vlastní svůj context, svůj deployment pipeline, své SLO. Team Topologies v praxi.

Anti-patterns, kterým se vyhýbáme: Shared database mezi službami (tight coupling). Synchronní řetězce volání (cascade failures). Příliš malé služby (nano-services overhead). God service, který ví všechno. Distribuované transakce přes 5+ služeb.

Deployment by neměl být událost. Pokud váš tým má „deployment window” v neděli v noci a všichni jsou v pohotovosti, něco je špatně. Stavíme deployment pipeline, kde push do mainu je rutina — automatizovaná, otestovaná, s okamžitým rollbackem.

Blue-green deployment: Dvě identické prostředí. Nová verze se nasadí na „green”, otestuje se, traffic se přepne. Pokud něco selže, přepneme zpět na „blue” za sekundy. Žádný downtime, žádný stress. Pro Kubernetes používáme Argo Rollouts s automatickými health checks.

Canary releases: Nová verze dostane 5% trafficu. Automatické metriky (error rate, latence, business KPI) rozhodnou, jestli pokračovat na 25%, 50%, 100% — nebo rollback. Celý proces automatizovaný, lidský zásah jen při eskalaci. Typicky 30-60 minut od push po full rollout.

Feature flags: Oddělení deploye od release. Kód je v produkci, ale funkce je vypnutá. Zapínáme postupně — interní uživatelé → beta → 10% → 100%. A/B testing zabudovaný. Kill switch na každou feature. LaunchDarkly, Unleash, nebo custom řešení podle potřeb.

Database migrations: Nejrizikovější část deploymentu. Používáme expand-contract pattern — nejdřív přidáme nový sloupec (expand), pak migrujeme data, pak odstraníme starý (contract). Žádné breaking changes, žádné locky na tabulkách. Flyway/Liquibase s automatickými rollback skripty.