Case Study
Engineering Team Lead
Jak vést databázovou refaktorizaci, aniž bychom zastavili produkt
(a proč to není jen technický problém).
Nikolai Baranov
nikolai.baranov@proton.me · +420 777 611 516
Březen 2026
01 / Nejdřív co nevím
Než navrhnu cokoliv konkrétního
Musím říct jednu věc na rovinu: nevím, na čem aplikace běží. A není to detail. V inzerátu na pozici se zmiňuje MariaDB — a pokud je to pravda, část technického přemýšlení, které by platilo pro PostgreSQL, tady prostě neplatí.
Proč záleží, jestli je to MariaDB nebo PostgreSQL: MariaDB (zejména v Galera Clusteru) koordinuje DDL operace jinak než PostgreSQL — ALTER TABLE v Galera je ve výchozím stavu blokující operace přes celý cluster (TOI mode). Nástroje jako pt-online-schema-change nebo gh-ost fungují s MariaDB, ale mají svá specifika. Pokud běží na Galera, archivační pipeline musí respektovat cluster sémantiku.
Každé níže popsané řešení dávám k dispozici jako konceptuální rámec — konkrétní implementace závisí na odpovědi na tuhle otázku. První věc, kterou udělám: zjistím přesnou technologii, verzi, konfiguraci. Nebudu to hádat.
02 / Jak o problému přemýšlím
Problém není objem dat
Zadání popisuje symptomy: pomalé migrace, nestabilita při velkém objemu, zpomalení delivery. Ale kořen problému je jiný.
Máme jednu tabulku, která obsluhuje dva fundamentálně odlišné případy použití. Aktivní data — záznamy obchodníků, kteří procházejí onboardingem, kde se schema mění spolu s produktem. A historická data — záznamy, které jsou de facto mrtvé: už se nemění, přistupuje se k nim zřídka a jejich schéma nemusí jít nikam.
Tyto dva světy mají odlišný životní cyklus, odlišnou frekvenci přístupu a odlišnou potřebu flexibility. Proto každá změna schématu — která se týká jen aktivních dat — musí projet přes miliony historických řádků, které s tou změnou nemají nic společného.
Neřešíme "jak zvládnout velký objem dat". Řešíme jak oddělit životní cykly dat tak, aby vývoj produktu mohl jít rychle, aniž by historická data za to platila.
03 / Tři konceptuální přístupy
Dříve než technologie
Než skočím na konkrétní technologie, je důležité pochopit, že existují tři různé konceptuální přístupy k tomuto problému — a každý z nich má jiné důsledky pro kód aplikace, provoz a tým.
A
Zlevnit migrace (tooling)
Necháme data tam, kde jsou, ale používáme nástroje (pt-osc, gh-ost), které dělají schema migrations online a bez dlouhého locku. Kód se nemění — problém růstu dat zůstává, jen ho oddálíme.
B
Archivační vzor
Přesuneme historická data do jiného úložiště. Hlavní DB zůstane malá. Kód musí vědět, kde hledat — potřebuje dvě připojení, dvě repository vrstvy, nebo smart routing.
C
Legacy layer přístup
Definujeme čáru v písku. Historická data jsou zmrazena, přistupuje se k nim přes dedikovanou read-only vrstvu v kódu. Archivní DB nikdy nedostane schema migration. Nový kód pracuje jen s aktivními daty.
Legacy layer jako architektonický vzor: nejde o technologii — je to architektonické rozhodnutí. Archivní DB nikdy nepotřebuje schema migrations. Nový kód je psán výhradně proti aktivním datům. Kontrakt je jasný: legacy data jsou read-only, forever. Nevýhoda: nový vývojář musí pochopit, že existují dva světy — dokumentace tohoto rozhraní je kritická.
04 / Co to znamená pro kód aplikace
Dopad na každodenní práci vývojářů
Toto je podle mě nejdůležitější část celé case study — a v diskusích o databázovém škálování se na ni zapomíná. Technologické rozhodnutí je sekundární. Klíčová otázka je: jak tato architektura ovlivní denní práci vývojářů?
Pokud přesuneme historická data do jiné DB, aplikace potřebuje dvě konfigurace DB připojení, oddělené repository třídy (MerchantRepository pro aktivní data, LegacyMerchantRepository pro archivní), jasnou sémantiku dotazů a rozhodnutí o tom, zda archivní data jsou dostupná přes stejné API nebo přes separátní "legacy" endpoint.
Klíčové rozhodnutí pro PM, ne pro techniku: Potřebujeme někdy dotazovat historická a aktivní data dohromady — například pro reporting nebo ML scoring? Pokud ano, náklady na udržení dvou DB jsou výrazně vyšší, protože potřebujeme JOIN přes hranice databází. Pokud ne, je to naopak čisté a jednoduché.
05 / Co bych doporučil
Moje preference — s podmínkami
Nestojím si za jednou odpovědí bez toho, aniž bych věděl víc o konkrétní situaci. Ale mohu říct, jak bych uvažoval při volbě přístupu.
?
Jsou historická data vstupem do aktivního rozhodování?
Pokud ANO
Potřebujeme plnohodnotný archiv s dotazovacím přístupem. Legacy layer je nedostatečný.
?
Jak rychle rostou data dál?
Lineárně
Archivace je nevyhnutelná. Tooling přístup ji jen oddálí.
0
Jaká je tolerance na downtime při migraci?
Nulová
Potřebujeme online schema change tooling — bez ohledu na zvolený archivační přístup.
Moje hypotéza — na základě zadání tak jak je popsáno: kombinace legacy layer přístupu a oddělené archivační DB. Legacy layer dává jasnou architektonickou hranici v kódu. Oddělená DB dává jasnou fyzickou hranici v infrastruktuře. Ale podmínky jsou: nevíme, jak je to s Galera, nevíme jestli historická data vstupují do scoringu, a nevíme, jak vypadá aplikační kód dnes. Tato preference je hypotéza k ověření — ne rozhodnutí.
06 / Prioritizace a postup
Tři fáze — nejdřív fakta
Nechci přijít s plánem, který ignoruje realitu delivery. Proto přistupuji takto:
T 1–3
Fáze 0 — Discoveryžádný kód
Zjistit přesný stack, verzi, konfiguraci DB — MariaDB standalone, Galera, nebo něco jiného? EXPLAIN ANALYZE na top 10 nejpomalejších dotazů — jsou pomalé kvůli objemu, nebo kvůli špatným indexům? Změřit délku dnešních schema migrations. S PM projít, co jsou historická data z businessového pohledu. Projít aplikační kód: jak se dnes přistupuje k historickým datům?
T 4–10
Fáze 1 — Pilotjedna tabulka
Vybrat nejproblematičtější tabulku s nejjednodušším přístupovým vzorem. Implementovat archivační pipeline pro tuto tabulku (cron nebo event-driven, záleží na stack). Vytvořit LegacyRepository vrstvu v kódu — záměrně jednoduchou, read-only, bez ORM magic. Neměnit aplikační API. Validace: schema migration na nyní menší tabulce — měříme čas, porovnáváme s baseline.
T 11–22
Fáze 2 — Rolloutzbylé tabulky
Rozšíření na zbývající problematické tabulky. Optimalizace indexů na hlavní DB — nyní menší tabulky, efektivnější indexy. Automatizace archivačního procesu a monitoring pipeline. Dokumentace je non-negotiable — co je legacy layer, proč existuje, jak s ním pracovat.
07 / Tým a spolupráce s PM
Vedení přes nejistotu
Nepřijdu s hotovým řešením a neoznamuji ho. Přijdu s analýzou z Fáze 0 a pozvu tým k diskusi o variantách. Vývojáři, kteří budou s archivační pipeline a legacy vrstvou pracovat každý den, vidí věci, které já nevidím — a pokud se cítí co-owners rozhodnutí, odvedou lepší práci.
Zároveň — rozhoduji. To není rozpor. Mohu přijmout challenge a změnit názor. Ale tým ode mě potřebuje jasnost, ne nekonečnou diskusi.
Navrhuji explicitní kapacitní split — například 30 % kapacity sprintu na tuto iniciativu, 70 % na produkt. Toto číslo není unilaterální — je to návrh k dohodě s PM. Bez explicitní dohody iniciativa vždy prohraje s urgentními tickety.
- PM nerozumí délce ALTER TABLE. Ale rozumí tomu, když řeknu: "Pokud chceme v Q3 přidat nový typ rizikového signálu, migrace zastaví onboarding obchodníků na dvě hodiny. Pokud tento problém neřešíme, za 12 měsíců to budou čtyři hodiny."
- Definice archivační linie (co je "staré") je primárně businessové rozhodnutí — PM musí být zapojený od začátku.
- Transparentní roadmapa — PM vidí kdykoli, kde jsme. Pokud PM potřebuje feature urgentně — diskutujeme kompromis, ne automatické blokování ani kapitulaci.
08 / Metriky
Definuji před začátkem, ne po
Všechny metriky sdílím otevřeně — s týmem i s PM.
Primární — výsledek iniciativy
| Metrika | Cíl | Poznámka |
|---|
| Délka schema migration na hlavní DB | < 5 min | Baseline měřím v Fázi 0 |
| p99 latence klíčových dotazů onboarding flow | bez regresů | Měřím před a po |
| Počet DB-related incidentů za měsíc | trend ↓ | Definuji, co je "DB incident" |
Sekundární — průběh iniciativy
| Metrika | Poznámka |
|---|
| Velikost hlavní DB a trend růstu | Zpomalení trendu po archivaci |
| Úspěšnost archivační pipeline | % runů bez chyby, od pilotu |
| Čas onboardingu nového vývojáře | Proxy metrika kvality dokumentace |
Anti-metrika
"Počet archivovaných záznamů" není cíl. Je to prostředek. Prezentovat ho jako úspěch je chyba — signalizuje, že jsme ztratili ze zřetele, co vlastně řešíme.
09 / Otázky, které zadání neřeší
Věci, které by mě trápily
Zadání říká "alespoň" — takže si dovolím přidat věci, o nichž bych chtěl mluvit.
⚖
GDPR a compliance historických dat — Shoptet Pay pracuje s daty obchodníků v platebním prostředí. Právo na výmaz (GDPR) platí i pro archivovaná data. Pokud archivní DB je "zmrazená", jak řešíme delete request? Toto musí být zodpovězeno před implementací, ne po.
ML
Co když historická data potřebujeme pro scoring? — Pokud ML model nebo scoring engine potřebuje historii obchodníka jako vstup pro aktivní rozhodování, pak legacy layer nestačí. Potřebujeme archivní DB, která je dotazovatelná — a to mění technologické a architektonické volby výrazně. Zjistím v Fázi 0.
🧪
Jak testujeme archivaci? — Migrace produkčních dat je nebezpečná operace. Nesmíme ji testovat na produkci. Potřebujeme staging prostředí s reprezentativními daty — anonymizovaný dump produkce. Bez toho je pilot v Fázi 1 hazard, ne inženýrství.
↩
Rollback plán — Co se stane, pokud archivační pipeline způsobí ztrátu dat nebo poruší konzistenci? Konkrétní postup, kdo co dělá a jak dlouho to trvá — ne "obnovíme z backupu", ale krok za krokem, připravený ještě před tím, než pustím první archivační job do produkce.
📖
Developer experience a onboarding — Každý nový vývojář, který přijde do týmu, musí pochopit, že existují dvě DB a proč. Pokud to není dobře dokumentováno, legacy layer se stane "tím záhadným kódem, do kterého se nikdo nechce dívat". Dokumentace je součástí Definition of Done pro každý archivační milestone.
10 / Závěr
Shrnutí přístupu
Tohle není problém, který se vyřeší jedním víkendem nebo sprint hackathonem. Ale není to ani roky práce. Je to 3–6 měsíců disciplinovaného, inkrementálního přístupu — kde každá fáze přinese hmatatelný výsledek a kde nikdy nezastavíme delivery produktu na neurčito.
1
Nejdřív fakta — stack, metriky, přístupové vzorce. Bez toho děláme architektonická rozhodnutí poslepu.
2
Problém je životní cyklus dat, ne objem. Toto rámování určuje celou strategii.
3
Legacy layer je architektonický vzor, ne technologická volba. Technologie se přizpůsobí.
4
Pilot na jedné tabulce — validujeme přístup, měříme výsledek, pak teprve rollout.
5
Archivační linie je businessové rozhodnutí — PM musí být u toho.
6
Dokumentace je součástí deliverable — ne afterthought. Je to podmínka, bez které iniciativa vyschne.
