Team deck • Medusa / Cloudflare / Coolify

Prezentace pro tým: jak to celé poběží od zákazníka až po deploy

Cíl je jednotná mapa pro business, dev, ops i support. Tohle není „jen infografika“, ale provozní blueprint: kde se odbavují zákazníci, kde jsou data, jak teče release přes Git a jak držet update-safe režim.

2-3 nody v Coolify Cloudflare edge + image pipeline Medusa + Payload + Odoo integrace Git + Docker + release governance

1) Co má tým po přečtení vědět

Rychlé vyjasnění rolí, zodpovědností a hranic systému, aby rozhodnutí o vývoji i provozu byla konzistentní.

Business/Owner

  • Kde vzniká konverze a co je kritická cesta checkoutu.
  • Co je „hotové“ platformou a kde je custom náklad.
  • Kde jsou provozní rizika (DB rollback, payment/ERP incidenty).

Tech/Product

  • Jak je oddělený storefront, commerce core, data a integrace.
  • Jak vypadá Git workflow a promotion do prostředí.
  • Jak držet customizace update-safe bez patchování core.

Ops/Support

  • Přes co se řídí deploy (UI/API/CLI) a kdo má approval.
  • Co monitorovat po release (SLO + business metriky).
  • Jaký je první rollback krok a kdy přepnout na DB recovery.

2) Customer handling flow: kde se odbavuje zákazník

Diagram lane-by-lane ukazuje, co se děje při browse/search/cart/checkout a kde se fyzicky vyřizuje požadavek zákazníka.

Zákaznický tok přes edge, runtime, commerce a data vrstvu
Lanes 1) Zákazník (web/mobile) 2) Cloudflare Edge 3) Experience Worker 4) Medusa/Payload (Coolify) 5) Data + ERP Browse Search / Filtrace Add to cart Checkout + platba Objednávka / účet PDP/listing požadavek Dotaz na výsledky Košíková akce Checkout step Historie / tracking CDN cache + WAF Cache rule + bot filt Rate limit guard Turnstile / WAF Edge caching účtu SSR render / route Query orchestrace Cart API volání Checkout orchestrace Customer/account BFF Medusa product API + Payload content API Product list API + search gateway Cart create/update + pricing engine Payment provider + order creation workflows Order status + account endpoints Postgres/R2 read Search index lookup Redis + stock reserve Order write + ERP event CRM/BI feed
Kde se „odbavuje zákazník“: UX odezvu drží edge + worker vrstva, zatímco stavové transakce (košík/objednávka/platba) řeší Medusa + data vrstva.

3) Datové vrstvy: co je transakční, co je výkonnostní, co analytické

Každá vrstva má jiný účel. Tohle je důležité, aby se třeba BI dotazy nepouštěly na primární write DB a aby cache nepřepisovala source of truth.

Datový blueprint pro 2-3 node architekturu
Experience data layer Edge cache, route cache, image variants (Cloudflare) Transactional core PostgreSQL (orders, cart, pricing, inventory source) Node C preferovaně separátně Volatilní runtime state Redis (session, queue, locking, workflow state) Search/index vrstva Meilisearch/alternativa, index sync z Medusy Media storage: R2 + Cloudflare image transformace Medusa + Payload Product/order APIs + content bloky + workflows Node B (commerce runtime) Sync & integration bus ERP/Odoo connector, webhooks, scheduled jobs Retry + DLQ + audit trail Observability & BI Logs/metrics + GA/GTM/Zaraz + BI read replica Analytika mimo primární write DB Zákaznické dotazy PDP, listing, search, cart, checkout, účet Obsluha přes edge + worker + commerce API Interní provoz Admin, pricing, expedice, ERP sync, feedy Medusa admin + integrační joby Rozhodování KPI, cohorty, merchandising, stock policy
Vrstva Source of truth Častá chyba Správný pattern
Objednávky/ceny/sklad PostgreSQL (Medusa core) Reporty nad primární DB pod trafficem Read replica / ETL pro BI
Search Index engine Filtrování těžkých dotazů jen přes transakční DB Index sync job + fallback list endpoint
Média R2 object storage Lokální disk containeru jako hlavní storage R2 + edge transformace + cache
Analytics Event pipeline / BI vrstva Mix business KPI s operativní DB telemetrií Oddělit operational monitoring vs business analytics

4) Git vizuálně: branch model od feature po produkci

Celý Git flow v jedné mapě: odkud se větví release, jak se promuje image, jak se vrací hotfix zpět do develop.

Branch topology + release body
Sprint start PR merge Feature freeze Release test Prod deploy Hotfix main develop release/2026-02 feature/* hotfix/* merge PR branch cut stage pass release tag urgent fix
Branch Prostředí Deploy trigger Owner
feature/* Preview / DEV namespace PR pipeline Developer + reviewer
develop DEV Auto deploy po merge Tech tým
release/* STAGE Manual promotion + integrační testy Tech lead + QA
main + tag PROD Deploy by image tag (schválení) Release owner
hotfix/* PROD + zpět do DEV Expedite pipeline On-call / tech lead

5) Deployment control tower: Docker + Coolify + Cloudflare

Kdo přesně řídí deployment, kde se staví image a jak se doručí stejný artefakt na všechny nody.

Control plane vs runtime plane
Management plane Git provider PR / branch rules tag release CI runner test + lint + build image scan Docker registry single artifact store immutable tags Coolify API/CLI/UI deploy by tag/uuid rollout / rollback app Release gate manual approval change freeze policy Runtime plane Node A Coolify control plane monitoring helpers Node B Medusa API + worker + Payload (pokud ne edge) payments, ERP workflows Node C PostgreSQL + Redis backup/restore Cloudflare edge Worker storefront + cache + WAF + image opt. customer response frontdoor
Oblast Hotové (ready-made) Custom práce
Git + deploy trigger Git provider integrace, webhooky, branch rules Promotion pravidla, release governance, approval chain
Docker + runtime Coolify orchestrace, registry pull, template služby Vlastní Dockerfile, migration gating, incident playbook
Cloudflare vrstva WAF, cache, Workers runtime, image transformace Konkretizace cache strategie, invalidace, SEO/analytics policy

Poznámka: multi-server deploy v Coolify je označený jako experimentální, proto držet rollback plan odděleně pro app a DB.

6) Provozní minimum po spuštění

Aby to fungovalo dlouhodobě, tým potřebuje společný rytmus release + monitoring + recovery.

Release cadence

  • Týdenní release slot + emergency hotfix slot.
  • Před PROD vždy stejný image tag, který prošel STAGE.
  • Po release 30 min heightened monitoring.

Monitoring a alerty

  • Technické: 5xx rate, latency, queue lag, DB lag.
  • Business: checkout drop, payment fail rate, order throughput.
  • Incident matrix: app rollback do 5-10 min, DB recovery podle RPO/RTO.
Doporučení: tenhle soubor používat jako „deck“ pro kick-off i retro. Operativní detaily (runbooky) držet odděleně v Notion/README.

Podklady (docs)

Coolify CI/CD Introduction, Coolify GitHub Overview, Coolify GitHub Actions, Coolify Docker Registry, Coolify API Auth, Coolify Deploy by tag/UUID, Coolify CLI, Coolify Multiple Servers, Coolify Scalability, Cloudflare Workers + Next.js, Cloudflare Image Transformations, Medusa Deployment, Medusa Payment Provider API, Medusa + Payload Guide, Odoo External API.