Mapy.com – architektúra služby
Mapová aplikácia pôsobí jednoducho. Zoomuješ, hýbeš mapou, všetko je plynulé. Lenže za tým je systém, ktorý musí zvládnuť tisíce requestov za sekundu, petabajty dát a globálnu latenciu. A presne v momente, keď chceš ísť z lokálnej služby do sveta, sa ti architektúra začne rozpadávať pod rukami.
Mikroservisy nie sú technické rozhodnutie
V Mapy.com majú architektúru postavenú na mikroservisoch. Nie preto, že je to trendy, ale preto, že bez toho by to organizačne nešlo.
Keď máš viac tímov a veľkú službu, potrebuješ, aby si každá časť vedela žiť vlastným životom. Vyvíjať sa nezávisle, deployovať sa bez čakania na ostatných a používať technológie, ktoré pre daný problém dávajú zmysel. Aj preto sa v Mapy.com stretáva Python, C++, Go aj JavaScript.
Lenže táto sloboda má veľmi konkrétnu cenu.
V momente, keď rozdelíš systém na mikroservisy, prestaneš volať funkcie a začneš posielať requesty po sieti. Zrazu riešiš latenciu, retry logiku a úplne nové typy chýb. A čo je ešte horšie, dáta už nemáš na jednom mieste.
Aj toto je téma, ktorá zaznela na CODECON #Bratislava 2025. Prednáška je dnes dostupná online a môžeš si ju pokojne vypočuť celú TU 👇👇:
V tomto článku ti medzitým prinášame výber toho najdôležitejšieho. Ber to ako ochutnávku alebo rýchly prehľad toho, o čom prednáška je, bez všetkých detailov a ukážok.
Keď jedna databáza zhodí všetko
Na papieri vyzerá mikroservisová architektúra jednoducho: servisy, databáza, hotovo.
Lenže práve toto je pasca. Ak viac služieb stojí nad jednou databázou, stačí, aby ju jedna z nich preťažila a padne celý systém.
V Mapy.com preto nejdú cestou jednej centrálnej databázy pre všetko. Stavajú to na viacerých úložiskách, oddelených zodpovednostiach a izolácii problémov.
Viac izolácie totiž znamená aj viac infraštruktúry, viac deployu, viac monitoringu a viac vecí, ktoré musíš automatizovať.
70 miliárd dlaždíc nie je edge case
Najzaujímavejšia časť celej prednášky je výdaj mapových dlaždíc.
Jedna dlaždica má 256 × 256 pixelov. Sama osebe nič špeciálne. Lenže keď chceš celý svet v 18 úrovniach zoomu, zrazu sa dostaneš na približne 70 miliárd dlaždíc. A to už znamená petabajty dát.
V tej chvíli je jasné, že nedáva zmysel všetko prerenderovať dopredu.
V Mapy.com to preto riešia kombináciou viacerých prístupov. Pre Česko používajú napríklad pred-render, pre zvyšok sveta render on demand a nad tým držia agresívne cachovanie.
Cache, ktorá sa nedá zdieľať
Lenže ani cache nie je zadarmo.
Keď sa bavíš o cache v rádoch terabajtov, nemáš luxus jednoducho ju “dať niekam bokom” a zdieľať medzi všetkými inštanciami. A ak máš viac inštancií, ktoré si cache nezdieľajú, veľmi rýchlo ti padá cache hit.
V Mapy.com preto použili riešenie:
- každá dlaždica patrí do konkrétneho shardu,
- request ide priamo na „správny“ server,
- existuje fallback, keď shard zlyhá.
Toto je presne ten typ rozhodnutia, ktorý na whiteboarde nevidíš, ale v produkcii rozhoduje o prežití.
Z disku do objektového úložiska
Pôvodne mali dáta na diskoch jednotlivých serverov. To funguje — až kým nezačneš škálovať.
V praxi to znamenalo presúvať obrovské objemy dát, riešiť konzistenciu pri výpadkoch a čoraz väčší operatívny tlak, ktorý s rastom len rástol.
Prechod na objektové úložisko tieto problémy výrazne zjednodušil. Zároveň však otvoril úplne novú triedu problémov, ktoré už neboli o kapacite, ale o rýchlosti.
Bez automatizácie to celé padá
Pri stovkách mikroservisov by manuálny deploy neprežil ani deň.
Aj preto majú v Mapy.com pipeline, ktorá drží konzistentný artefakt naprieč prostrediami a umožňuje celý systém bezpečne posúvať dopredu.
Až v tomto bode začnú mikroservisy fungovať tak, ako si ich ľudia radi kreslia do architektonických diagramov. Bez tejto vrstvy by z nich zostala len zbytočná komplexita…
Stále hladný?
Okrem tejto prednášky sme na CODECON #Bratislava 2025 mali množstvo ďalších na rôzne témy. Ak ťa toto zaujalo, určite si prídeš na svoje aj pri ostatných.
Celý prístup k nezostrihaným prednáškam nájdeš na YouTube: