Master's Thesis

Web Content Aggregation Platform based on Microservices

Final Thesis 4.45 MB

Author of thesis: Bc. Adam Políček

Acad. year: 2025/2026

Supervisor: doc. Ing. Radek Burget, Ph.D.

Reviewer: Ing. Radek Hranický, Ph.D.

Abstract:

This master's thesis designs, implements and deploys a microservices-based platform for web content aggregation, demonstrated on the Czech real-estate market through three reference bot services that scrape Sreality.cz, Bazos.cz and Bezrealitky.cz. Each bot is a self-contained module that owns its scraping pipeline, its private data collections, its per-user matcher and its notification template; supporting a new source amounts to deploying one additional container against a small contract. The system runs on a heterogeneous K3s cluster connected by a Tailscale mesh VPN, with MongoDB as the shared document store, RabbitMQ for asynchronous events, and a Nuxt~3 Backend-for-Frontend as the only externally exposed component. Continuous delivery is driven by GitOps with Flux~CD, SOPS-encrypted secrets and Flagger-driven canary roll-outs of the frontend. The deployed system is verified end-to-end through OpenTelemetry instrumentation surfaced in the Grafana, Prometheus, Loki and Tempo stack, which also serves as the primary evidence channel for the evaluation chapter

Keywords:

microservices, web content aggregation, web scraping, Kubernetes, K3s, MongoDB, RabbitMQ, Nuxt, GitOps, OpenTelemetry, observability, distributed systems, real estate

Date of defence

24.06.2026

Result of the defence

Defended (thesis was successfully defended)

znamkaAznamka

Grading

A

Process of defence

Student nejprve prezentoval výsledky, kterých dosáhl v rámci své práce. Komise se poté seznámila s hodnocením vedoucího a posudkem oponenta práce. Student následně odpověděl na otázky oponenta a na další otázky přítomných. Komise se na základě posudku oponenta, hodnocení vedoucího, přednesené prezentace a odpovědí studenta na položené otázky rozhodla práci hodnotit stupněm A.

Topics for thesis defence

  1. Jak byste objektivně ověřil správnost matchingu, tj. že systém neposílá notifikace na nerelevantní inzeráty a zároveň žádné relevantní nevynechává?
  2. Která část řešení by podle vás jako první limitovala výkon (začala být "úzkým hrdlem"), pokud by masivně vzrostl počet uživatelů a jejich konfigurací? Jaké optimalizace systému byste případně navrhl pro zlepšení škálovatelnosti?
  3. Uvažujte, že by některý portál výrazně změnil strukturu stránky nebo API. Jak by bylo možné v systému detekovat, že nejde o stav "žádné nové inzeráty", ale o chybu scrapingu?
  4. Detekuje aplikace např. změnu ceny inzerátu?

Language of thesis

English

Faculty

Department

Study programme

Information Technology and Artificial Intelligence (MITAI)

Specialization

Information Systems and Databases (NISD)

Composition of Committee

prof. RNDr. Alexandr Meduna, CSc. (předseda)
doc. Ing. Radek Burget, Ph.D. (místopředseda)
RNDr. Marek Rychlý, Ph.D. (člen)
Ing. Šárka Květoňová, Ph.D. (člen)
Ing. Vladimír Veselý, Ph.D. (člen)
Ing. Jiří Hynek, Ph.D. (člen)

Supervisor’s report
doc. Ing. Radek Burget, Ph.D.

Pan Políček samostatně vytvořil podle mého názoru propracované distribuované řešení pro sběr dat včetně demonstračního praktického nasazení. Postup řešení pravidelně konzultoval. Proto jeho práci celkově hodnotím jako nadprůměrnou a navrhuji hodnotit stupněm A.

Evaluation criteria Verbal classification
Information about assignment

Cílem práce byl návrh a implementace distribuované modulární platformy pro sběr dat z webových zdrojů ve velkém měřítku a jejich další zpřístupnění. Jedná se o vlastní iniciativu studenta. Zadání považuji z pohledu vedoucího za splněné. 

Activity during solution, consultations, communication

Práce byla dokončena v termínu a měl jsem možnost připomínkovat výslednou podobu aplikace i technické zprávy.

Publication activity, awards
Work with literature

Student samostatně vyhledával a využíval dostupné informační zdroje.

Activity during solution, consultations, communication

Student pracoval převážně samostatně, postup řešení, zejména návrh celé platformy však podrobně konzultoval. Na konzultace byl velmi dobře připraven.

Points proposed by supervisor: 92

Grade proposed by supervisor: A

Reviewer’s report
Ing. Radek Hranický, Ph.D.

Pan Políček vypracoval prakticky orientovanou diplomovou práci s rozsáhlým realizačním výstupem. Implementované řešení vhodně kombinuje existující technologie a aplikuje je na konkrétní problém sledování realitních inzerátů z více zdrojů. Oceňuji zejména návrh modulární mikroslužbové architektury, testování v reálném provozu a podporu orchestrace. Slabší stránkou je kratší provozní ověření, absence komplexnějších zátěžových testů a místy hutnější výklad.


Celkově práci hodnotím jako výbornou (A).

Evaluation criteria Verbal classification Points
The extent to which the requirements of the assignment have been met

Evaluation level: assignment fulfilled

Zadání považuji za splněné v celém rozsahu.

Extent of the technical report

Evaluation level: is within the usual extent

Dle https://app.fit.vut.cz/theses-checker práce čítá 92,23 normostran.

Presentation level of the technical report

Práce má logickou strukturu a jednotlivé kapitoly na sebe přirozeně navazují. Místo vyčerpávající obecné teorie student v kapitole "State of the Art" přímo hodnotí existující technologie a jejich použitelnost pro navržené řešení. Oceňuji, že autor pouze nepopisuje výsledné řešení, ale u zásadních rozhodnutí vysvětluje také motivaci použitých metodik a zvažované alternativy. Z práce je tak zřejmé, že výsledná architektura vznikla jako promyšlený kompromis mezi modularitou, provozní složitostí a možností dalšího rozšiřování.

Text doplňuje velké množství názorných schémat a tabulek, díky kterým je možné lépe pochopit strukturu systému, tok dat a vztahy mezi komponentami. Pozitivně hodnotím, že klíčové části, např. modulární kontrakt botů a notifikační pipeline, jsou popsány velmi precizně a do značné technické hloubky. Silnou stránkou práce je také přehledné zhodnocení splnění jednotlivých požadavků s použitím přehledové tabulky 5.2.

Vyhodnocení vytvořeného řešení student realizoval na reálně nasazeném systému. Pozitivně hodnotím vyzkoušení "end-to-end" průchodu systémem, ověření funkčnosti jednotlivých mikroslužeb a kontinuálního běhu botů. Jistým omezením je kratší délka provozu (24 hodin). Není také jasné, jak velkou zátěž (počet uživatelů, botů, inzerátů) systém zvládne, případně jak reálně zvládá chybové stavy jako např. pád některé mikroslužby.

Práci bych dále vytknul, že automaticky předpokládá čtenáře dobře obeznámeného s cloud-native technologiemi. Mnohé pasáže jsou velmi hutné a kombinují více pokročilých technologií najednou (Kubernetes, GitOps, RabbitMQ, BFF apod.). Čtenář, který nemá s těmito systémy praktickou zkušenost, tak sice chápe, z jakých komponent se systém skládá, ale hůře sleduje, proč jsou potřeba a jaký praktický problém v architektuře řeší. Práci by pomohl názorný příklad demonstrace funkcionality: nový inzerát, zpracování botem, shoda, notifikace. Popisky některých obrázků pak obsahují podstatné technické informace, které by bylo vhodnější přesunout do hlavního textu.

88
Formal preparation of a technical report

Formální stránka práce je na velmi vysoké úrovni. Klíčové pojmy jsou písmem vhodně odlišeny. Vložené obrázky a tabulky jsou korektně odkazovány z textu. U obr. 4.6 je dosti malé písmo a obtížně se čte. U snímků obrazovky by pro lepší čitelnost bylo vhodnější zvolit světlý režim, nebo invertovat barvy.

Technická zpráva je psána pěknou odbornou angličtinou a dobře se čte. Mírně rušivě působí kombinování americké a britské angličtiny, např.: "normalize" vs. "normalise" nebo "centralized" vs. "centralised". Pravopisných chyb je v práci minimum. Stylistická stránka jazyka je také kvalitní, jen občas se objevují zbytečně komplikovaná a těžkopádná souvětí.

U anglické práce by měl být uveden rozšířený abstrakt v češtině. Standardní český abstrakt obsahuje zvláštní spojení jako "bot službami" nebo "sklízejí inzeráty" a působí tak spíše jako strojový překlad anglického abstraktu.

94
Work with literature

Bibliografie je poměrně obsáhlá. Celkově čítá 57 literárních pramenů, které jsou tématicky relevantní k oblastem mikroslužeb, zpracování dat z webu, databázím, monitoringu i orchestraci. Pozitivně hodnotím, že provedená analýza existujících řešení přímo podporuje pozdější architektonická rozhodnutí.

Většinu zdrojů tvoří produktové dokumentace, webové stránky a online manuály jednotlivých technologií. To je u prakticky orientované práce pochopitelné, avšak rešeršní část má pak spíše charakter srovnání technologií než hlubší akademické analýzy relevantních principů. Ocenil bych zde více skutečně vědeckých zdrojů k oblastem mikroslužeb a distribuovaných systémů. V seznamu literatury se na několika místech objevuje dvojitá tečka za "Inc".

93
Realisation output

Realizační výstup je rozsáhlý a dobře organizovaný do několika vzájemně komunikujících mikroslužeb. Tyto zahrnují mikroslužbu na bázi Nuxt s frontendem ve VueJS a BFF v jazyce TypeScript, tři služby botů pro realitní zdroje v jazycích Python a TypeScript, konfigurační formuláře v HTML a e-mailový notifikátor v jazyce Go. Součástí řešení je také perfektní podpora pro orchestraci v rámci lokálního i produkčního nasazení (Docker Compose, Kubernetes apod.). Rozsahově studentem vytvořené zdrojové kódy odhaduji na cca 16 tisíc řádků. Kód je čitelný a srozumitelný. Oceňuji především modulární koncepci botů, které tvoří dedikované komponenty s různou odpovědností. Součástí je také několik automatizovaných testů.

Realizační výstup je plně funkční a student mi jej osobně demonstroval. Oceňuji přiložený soubor README, který jasně vysvětluje, jak systém zprovoznit. Uvítal bych však také návod, jak přidávat nové boty.

99
Usability of results

Řešení je dobře využitelné jako základ praktické platformy pro sledování webového obsahu z více zdrojů. Přestože student řešil oblast realit, řešení má širší potenciál, např. pro monitoring pracovních nabídek, bazarových inzerátů, nebo jiných často se měnících katalogů. Výhodou je snadné přidání nových botů pro další zdroje, aniž by bylo nutné zásadně měnit zbytek systému. Díky dockerizaci a další orchestrační podpoře je řešení prakticky ihned nasaditelné do reálného prostředí. Před produkčním nasazením by však bylo vhodné realizovat delší provozní ověření, důkladnější testování zátěže a odolnosti vůči chybovým stavům.

The difficulty of the assignment

Evaluation level: moderately difficult assignment

Topics for thesis defence:
  1. Která část řešení by podle vás jako první limitovala výkon (začala být "úzkým hrdlem"), pokud by masivně vzrostl počet uživatelů a jejich konfigurací? Jaké optimalizace systému byste případně navrhl pro zlepšení škálovatelnosti?
  2. Uvažujte, že by některý portál výrazně změnil strukturu stránky nebo API. Jak by bylo možné v systému detekovat, že nejde o stav "žádné nové inzeráty", ale o chybu scrapingu?
  3. Jak byste objektivně ověřil správnost matchingu, tj. že systém neposílá notifikace na nerelevantní inzeráty a zároveň žádné relevantní nevynechává?
Points proposed by reviewer: 91

Grade proposed by reviewer: A

Responsibility: Mgr. et Mgr. Hana Odstrčilová