A microservices platform that brings independently developed modules together into a single department portal - from architecture and integration through automated deployment to monitoring in production.
For years, the existing Department of Informatics portal was little more than a static business card - no sign-in, no content management, no way to extend it. The goal was not just a visual refresh, but to build a platform that can be extended with new modules without touching its core.
New functionality is built as a separate module. Each module is independent - adding or changing one does not affect the other modules or the system core.
The system core handles sign-in with both university Microsoft Entra ID accounts and local invitation-based accounts. Modules don't deal with authentication or roles themselves, they simply use them.
The project originated in project-based courses and serves as a foundation on which students can build their own extension modules in future semesters.
The thesis covers two areas: integration deals with how modules work together, and orchestration with how they get to production automatically.
Designing a microservices architecture and implementing the key modules so that they are technologically independent yet cooperate reliably - with shared sign-in, data and events.
Containerization and CI/CD pipelines that automate builds, tests, delivery to production environments and real-time system monitoring.
The thesis implements three modules - user management, department portal content and study materials. They are complemented by a shared service that brings semantic search across the whole system.
Single sign-in and user management
Sign-in with university accounts (Microsoft Entra ID) as well as local invitation-based accounts. Management of users and their global and module-specific roles, including public profiles.
Department portal content
News with a WYSIWYG editor and search support, a list of department members synchronized from LDAP, courses and research projects.
Study materials
Study materials for courses organized into chapters. Demonstrates how new extension modules are added to the system.
Users don't need to know the exact words - they just describe what they're looking for and the system finds content matching the meaning of their query. Behind the scenes, the service creates vector representations of content (embeddings) using a local ONNX model and stores them in a Qdrant DB. Both the portal and study materials use it this way.
A look at the individual components and their relationships within the system
The modular system consists of a web client, four services, their own databases and infrastructure for messaging and observability. The services are deployed as containers via Docker Compose.
A unified user interface built with Angular. It communicates with all modules through an Nginx API gateway that routes requests to the appropriate services - so the client acts as a single portal.
IdentityService issues JWT tokens signed with RSA asymmetric cryptography, manages global and module roles and publishes user events via the Event Bus. It connects the system to Microsoft Entra ID and the FRI LDAP.
PortalService manages news, department members, courses and research projects. Via the Event Bus it maintains a shadow table of users and synchronizes department members from the FRI LDAP.
An extension module for study materials organized into chapters. It demonstrates how new modules are added to the system - without touching the core or the other modules.
A universal service for generating embeddings and semantic search - it uses a local ONNX model and the Qdrant vector database. Both Portal and Courses call it synchronously over gRPC when searching news and study materials.
The RabbitMQ Management UI and the Grafana observability stack (Grafana + Loki + Tempo). Used by administrators for monitoring and by developers for diagnostics - accessible only via the UNIZA VPN.
Two custom libraries used across the system's .NET services.
Published via GitHub Packages.
A custom implementation of the mediator pattern - it separates the API layer from business logic via IMediator.SendAsync(). Created as a replacement for MediatR after its license change.
// Controller - IMediator via DI (primary ctor) public class ArticlesController(IMediator mediator) : ControllerBase { [HttpGet("{slug}")] public async Task<IActionResult> Get(string slug) { var article = await mediator.SendAsync( new GetArticleQuery(slug)); return Ok(article); } }
// Request + handler (.Business project) public record GetArticleQuery(string Slug) : IRequest<ArticleDto>; public class GetArticleHandler(AppDbContext db) : IRequestHandler<GetArticleQuery, ArticleDto> { public Task<ArticleDto> HandleAsync( GetArticleQuery q, CancellationToken ct) { // load the article + map it to ArticleDto } }
// Program.cs // AddMediator discovers and registers all // IRequest + IRequestHandler in the given assembly builder.Services.AddMediator( typeof(GetArticleQuery).Assembly);
An abstraction over RabbitMQ - one service publishes events, others consume them, while the library takes care of the message broker communication details. Services thus communicate with each other asynchronously.
// IdentityService - IEventBus via DI public class AuthService(IEventBus eventBus) { public async Task Register(UserProfile user) { // ... save the user await eventBus.Publish( new UserRegisteredEvent(user)); } }
// Event + consumer (PortalService) [Exchange(prefix: "IdentityService")] public record UserRegisteredEvent(UserProfile User); public class UserRegisteredConsumer(AppDbContext db) : IConsumer<UserRegisteredEvent> { public Task Consume(UserRegisteredEvent msg) { // synchronize the shadow table } }
// Program.cs // AddEventBus connects RabbitMQ and auto-registers // all IConsumer<T> in the given assembly builder.Services.AddEventBus( typeof(UserRegisteredConsumer).Assembly);
Once developed, the system needs to be reliably delivered to the production environment for end users, and its operation then monitored so that any errors are caught early. The second area of the thesis automates these phases - from code changes all the way to error notifications.
The system is split into repositories by module, gathered in a single private GitHub organization - giving the whole team one place with an overview of all parts of the system. Each repository has its own CI/CD pipelines, sensitive data is kept out of the code in GitHub Secrets, and the custom libraries are published to a private NuGet feed via GitHub Packages.
WebClient, IdentityService, PortalService and infrastructure - RabbitMQ and the Grafana stack. The core services are deployed together.
CoursesService - the study materials module. Demonstrates how the system is extended with an independently deployable module.
VectorIndexerService - an internal gRPC service for semantic search (embeddings via ONNX + Qdrant). It doesn't belong to any module.
NuGet package MIS.Mediator - an in-process CQRS mediator. Published to GitHub Packages.
NuGet package MIS.EventBus - an abstraction over RabbitMQ. Published to GitHub Packages.
A skeleton for building new modules - ready-made structure, configuration and pipelines to get started.
Internal technical documentation for the whole development team - architecture, onboarding of new members, conventions and module integration guidelines.
A custom GitHub Action - during deployment it replaces placeholders in .env with real values from Secrets.
Four types of GitHub Actions workflows automate change validation, production deployments, database migrations and publishing new versions of the custom libraries.
.nupkgA manual trigger from the GitHub UI kicks off four consecutive jobs. Both build (ci) and deploy (cd) are extracted into reusable workflows, so they can also be run on their own.
vYY.MM.DD.Ndocker compose build.env (replace-tokens-action).env to the serverdocker compose up/healthRuns on a self-hosted runner - build and deploy on the same server.
Every service sends logs and distributed traces via OpenTelemetry to a central monitoring system. The trace detail shows which services a request passed through. Thanks to Trace ID correlation, only the logs related to a given trace are shown.
One request, one Trace ID - across all services.
In the Grafana dashboard, just click a request in the trace list to see its span timeline along with all related logs correlated by Trace ID. This makes finding the root causes of errors in a distributed system much easier.
When an error is logged, Grafana automatically notifies the administrators. Via a Power Automate webhook, a notification arrives in Teams with a list of errors and a button linking straight to the trace in Grafana.
Selected features of the deployed system, grouped by module.
The screenshots capture the system as it was at the time of the thesis defense.
Software Engineer
I'm a graduate of the Faculty of Management Science and Informatics at the University of Žilina, where I defended my master's thesis Modular Web System - Integration and Orchestration of Modules.
It gave me valuable experience not only with development, but above all with system design and architectural decisions at the level of an entire system - from designing a microservices architecture through automated deployment to monitoring and alerting in production. Looking at software as a whole is what I enjoy and what keeps pushing me forward.
Earlier, I also defended my bachelor's thesis The Web Part of the First Responder System.