Starszy Architekt Python / Lider Techniczny (Wysokie Obciążenie TDS: Litestar + Granian)

O projekcie:

Tworzymy licencjonowany produkt self-hosted (SaaS) do automatyzacji, routingu i walidacji ruchu w wysoko konkurencyjnych branżach (Fintech, iGaming, Crypto). W zasadzie jest to system dystrybucji ruchu (TDS) o wysokiej prędkości z modułami autologowania, kaskadowego routingu i symulacji odcisków (Spoofing).

Sytuacja w zespole:

Mamy już silnego programistę produktu Middle/Senior (Ilja), który doskonale radzi sobie z zadaniami związanymi z logiką biznesową: panele, role (SuperAdmin, Właściciel, Kupujący), integracje z zewnętrznymi API brokerów i interfejsy.

Potrzebuję Tech Leada / Architekta, który zbuduje dla niego wysoko obciążoną podstawę, przejmie infrastrukturę serwerową i stanie się absolutnym "gatekeeperem" jakości kodu.

🎯 Twoje pierwsze zadanie (Milestone 1): Podstawowa architektura bramy i CI/CD

Zanim zaczniemy wdrażać funkcje produktowe i przenosić stary kod, musimy położyć odpowiednią podstawę.

Technologiczny stos rdzenia:

* Framework: Litestar + msgspec (dla maksymalnej prędkości serializacji DTO).

* Serwer WWW: Granian (oparty na Rust ASGI worker).

* Baza danych i cache: PostgreSQL (asyncpg + SQLAlchemy 2.0), Redis.

* Infrastruktura: Docker, GitHub Actions.

Co konkretnie należy zrobić na pierwszym etapie:

* Projektowanie czystej architektury na GitHubie:

* Zrealizować warstwową strukturę projektu (API, Domain, Services, Infrastructure) specjalnie pod przyszłe przeniesienie logiki biznesowej przez drugiego programistę.

* Skonfigurować podstawowe hierarchiczne routowanie Litestar i szablony DTO.

* Konteneryzacja (Docker):

* Napisać Dockerfile do budowy lekkiego obrazu z Granian.

* Przygotować docker-compose.yml do lokalnego uruchomienia zestawu: App + PostgreSQL + Redis.

* Gatekeeping i CI/CD:

* Skonfigurować Branch Protection dla gałęzi main: zakaz bezpośrednich pushów.

* Napisać pipeline GitHub Actions na Pull Requests (linter Ruff, typizacja MyPy, podstawowe testy Pytest). Pipeline powinien blokować Merge w przypadku błędów. Cały kod programisty produktu będzie przechodził przez twoje Code Review.

* Doświadczenie dewelopera (DX):

* Przygotować szczegółowy README.md z instrukcjami dla zespołu (jak uruchomić projekt, jak uruchomić testy, zasady pisania kodu w nowym stosie).

✅ Kryteria akceptacji (Definition of Done) pierwszego etapu:

* Architektura została załadowana do udostępnionego prywatnego repozytorium GitHub.

* Projekt uruchamia się lokalnie bez błędów przez docker-compose up.

* Dostępny jest testowy /health endpoint, którego odpowiedź pochodzi z serwera Granian.

* Przy tworzeniu Pull Requesta z błędem lintera lub typizacji — GitHub Actions poprawnie to wychwytuje i nie pozwala na Merge.

Aby odpowiedzieć:

Proszę krótko opisać swoje doświadczenie w pracy z systemami High-Load lub w niszach AdTech/Arbitrażu, a także podać swoją ocenę co do terminów i budżetu na realizację tego pierwszego Milestone.