01 · Foundation
Infrastructure & Identity
Shared Nginx reverse proxy, Keycloak identity, RustFS S3-compatible storage and Outline Wiki.
outline_wiki ↗Independent engineering portfolio · Single-host homelab
Homelab
Data Platform.
A working, independently implemented Data Engineering laboratory inspired by architectural patterns refined over three years of production engineering experience.
One platform. Connected components.
An architectural overview of the existing homelab services. Arrows show intended roles and logical relationships; they do not imply a completed end-to-end pipeline.
Source repositories
Independent repositories with runnable configuration, architecture decisions, setup instructions and operational constraints.
02 · Orchestration
Apache Airflow
LocalExecutor, Scheduler, DAG Processor, PostgreSQL metadata and Keycloak authentication.
homelab-airflow ↗03 · Lakehouse
Spark + Iceberg
Single-host Spark Standalone, JupyterHub, Iceberg REST Catalog and S3 object storage.
homelab-sparkice ↗04 · Analytics
ClickHouse + PostgreSQL
SQL analytics, columnar OLAP storage, administration tools and Metabase dashboards.
homelab-analytics-stack ↗05 · Graph analytics · Cloud.ru VM
Neo4j · Graph Data Science
An independently deployed Neo4j graph database on a Cloud.ru virtual machine. Used for exploring relationships among entities, graph structures, traversals and graph algorithms. The repository documents the Docker-based environment and Graph Data Science setup.
homelab-neo4j ↗Independent engineering case studies
Working prototypes and independently developed applications informed by practical engineering experience. These projects are not part of the core platform deployment and are presented with their actual implementation boundaries.
05 · Event-driven integration · API-first
Messaging Event Hub
Implemented: Telegram adapter · MAX adapter planned
An independently built event and message delivery core based on FastAPI and PostgreSQL. Telegram webhooks are normalized into durable events; routes and workers deliver them to business services, while an authenticated API accepts outbound commands. The design includes idempotency, leases, retries and service-scoped publishing permissions.
Telegram→Webhook / API→PostgreSQL queue→Worker→Business service
Architecture context: comparable MAX-oriented messaging workflows have operated under integration constraints that required direct database operations (SELECT, INSERT, UPDATE). This independent implementation explores an API-first boundary to decouple business services from transport and persistence details. It does not reuse employer code or claim an implemented MAX adapter.
Explore messaging-event-hub ↗
06 · Applied AI · RAG
Evidentum
Hackathon project · 3rd place
A hackathon-born AI research prototype for searching, comparing and synthesizing Russian and international clinical guidelines. The system combines PDF/HTML ingestion, embeddings, PostgreSQL pgvector and full-text retrieval, reranking, and LLM-generated answers with references to source passages.
Clinical guidelines→Ingestion→Hybrid retrieval→LLM synthesis
Built as a team hackathon project and subsequently extended as an engineering portfolio artifact. Source references support traceability but do not establish medical validity; Evidentum is not a clinically validated decision-support system.
Explore Evidentum ↗
Production-informed engineering
This platform is not a cloned employer system. It is an independently built laboratory that demonstrates design patterns learned through real data-platform engineering.
Engineering pattern
Separate orchestration from compute
Airflow manages task state and scheduling. Spark provides independent distributed data processing.
Engineering pattern
Reuse shared platform services
Identity, network routing and object storage are provided as shared infrastructure rather than copied per application.
Engineering pattern
Document limits and failure modes
Single-host resource budgets, setup dependencies and smoke tests are documented explicitly.
All public material uses independent configurations and demonstration-oriented descriptions. No employer source code, production datasets, credentials, internal endpoints or undisclosed architecture details are published.
Next engineering milestones
Planned capabilities are explicitly distinct from the working components above.
Planned
Kafka + NiFi
Event ingestion, flow management and integration with the existing platform.
Planned
End-to-end demo
A synthetic-data scenario linking ingestion, orchestration, processing, lakehouse storage and analytics.