programista-backend
Tworzenie backendu dla Skyeng to nie „zrobienie strony”. To budowa cyfrowego miasta, działającego 24/7. Moim zadaniem jest zaprojektowanie i zbudowanie całej jego niewidocznej infrastruktury: silnika, który pozwala tysiącom ludzi jednocześnie spotykać się, uczyć i komunikować w czasie rzeczywistym.
Architektura: Żegnaj, monolicie
Od razu zdecydowano się zrezygnować z monolitu na rzecz mikroserwisów. Taki skomplikowany projekt musi być elastyczny i odporny na awarie. Podzieliłem całą logikę na niezależne usługi:
Usługa Auth: Kontrola dostępu (JWT, role).
Usługa Scheduler: Mózg platformy. Żongluje tysiącami lekcji, uwzględniając strefy czasowe nauczycieli z Brazylii i uczniów z Władywostoku.
Usługa Matching: Inteligentne dopasowanie idealnej pary „uczeń-nauczyciel”.
Usługa Billing: Zarządzanie subskrypcjami, płatnościami i wynagrodzeniami. Maksymalna niezawodność.
Usługa Classroom: Dyrygent lekcji, działający w czasie rzeczywistym.
Łączność między nimi — przez asynchroniczną szynę wiadomości (np. RabbitMQ), aby awaria jednej usługi nie wpłynęła na cały system.
Serce systemu: Wirtualna klasa
Interaktywna klasa Vimbox to najtrudniejsza i najciekawsza część. To aplikacja stateful, w której opóźnienia są niedopuszczalne.
Tutaj postawiłem na WebSockets. Kiedy nauczyciel rysuje na wirtualnej tablicy, jego przeglądarka nie bombarduje serwera zapytaniami. Zamiast tego między nim, serwerem a uczniem ustanowiony jest stały kanał. Klient nauczyciela wysyła zdarzenie (np. {"event": "draw", "coords": [x1, y1, x2, y2]}), moja usługa w Go łapie je i natychmiast przesyła uczniowi do narysowania na jego płótnie. Cały proces zajmuje milisekundy, zapewniając pełną synchronizację.
Przesyłanie strumieni wideo i audio przez własne serwery to bezsensowny ciężar. Do tego używa się WebRTC, który pozwala przeglądarkom komunikować się bezpośrednio (peer-to-peer). Mój backend jedynie „poznaje” je, zapewniając sygnalizację serwisową do nawiązania połączenia.
Technologie i infrastruktura
Stos technologiczny został dobrany do konkretnych zadań dla maksymalnej wydajności:
Języki: Go dla wysokoobciążonych usług czasu rzeczywistego (Classroom), Python (FastAPI) dla pozostałej logiki biznesowej.
Bazy danych: PostgreSQL jako główna relacyjna baza, Redis do cache'owania wszystkiego i wszędzie, a także jako broker dla WebSockets.
Infrastruktura: Wszystkie usługi są zapakowane w kontenery Docker i zarządzane przez orkiestrator Kubernetes. To zapewnia automatyczne skalowanie: jeśli obciążenie rośnie, Kubernetes sam uruchamia nowe kopie potrzebnej usługi.
Główne wyzwanie: Strefy czasowe
To cichy koszmar każdego globalnego projektu. Rozwiązanie jest jedno i nie podlega dyskusji: na backendzie wszystkie daty i czasy są przechowywane wyłącznie w UTC. Absolutnie wszystko. A już aplikacja kliencka odpowiada za konwersję na lokalny czas użytkownika. Jakiekolwiek inne podejście to gwarantowana katastrofa w przyszłości.
W rezultacie, moja praca to nie tylko „kodowanie funkcji”. To inżynieria skomplikowanego, odpornego na awarie i szybkiego systemu rozproszonego, który nie zawiedzie w godzinach szczytu, gdy tysiące ludzi na całym świecie naciskają przycisk „Rozpocznij lekcję”.
Architektura: Żegnaj, monolicie
Od razu zdecydowano się zrezygnować z monolitu na rzecz mikroserwisów. Taki skomplikowany projekt musi być elastyczny i odporny na awarie. Podzieliłem całą logikę na niezależne usługi:
Usługa Auth: Kontrola dostępu (JWT, role).
Usługa Scheduler: Mózg platformy. Żongluje tysiącami lekcji, uwzględniając strefy czasowe nauczycieli z Brazylii i uczniów z Władywostoku.
Usługa Matching: Inteligentne dopasowanie idealnej pary „uczeń-nauczyciel”.
Usługa Billing: Zarządzanie subskrypcjami, płatnościami i wynagrodzeniami. Maksymalna niezawodność.
Usługa Classroom: Dyrygent lekcji, działający w czasie rzeczywistym.
Łączność między nimi — przez asynchroniczną szynę wiadomości (np. RabbitMQ), aby awaria jednej usługi nie wpłynęła na cały system.
Serce systemu: Wirtualna klasa
Interaktywna klasa Vimbox to najtrudniejsza i najciekawsza część. To aplikacja stateful, w której opóźnienia są niedopuszczalne.
Tutaj postawiłem na WebSockets. Kiedy nauczyciel rysuje na wirtualnej tablicy, jego przeglądarka nie bombarduje serwera zapytaniami. Zamiast tego między nim, serwerem a uczniem ustanowiony jest stały kanał. Klient nauczyciela wysyła zdarzenie (np. {"event": "draw", "coords": [x1, y1, x2, y2]}), moja usługa w Go łapie je i natychmiast przesyła uczniowi do narysowania na jego płótnie. Cały proces zajmuje milisekundy, zapewniając pełną synchronizację.
Przesyłanie strumieni wideo i audio przez własne serwery to bezsensowny ciężar. Do tego używa się WebRTC, który pozwala przeglądarkom komunikować się bezpośrednio (peer-to-peer). Mój backend jedynie „poznaje” je, zapewniając sygnalizację serwisową do nawiązania połączenia.
Technologie i infrastruktura
Stos technologiczny został dobrany do konkretnych zadań dla maksymalnej wydajności:
Języki: Go dla wysokoobciążonych usług czasu rzeczywistego (Classroom), Python (FastAPI) dla pozostałej logiki biznesowej.
Bazy danych: PostgreSQL jako główna relacyjna baza, Redis do cache'owania wszystkiego i wszędzie, a także jako broker dla WebSockets.
Infrastruktura: Wszystkie usługi są zapakowane w kontenery Docker i zarządzane przez orkiestrator Kubernetes. To zapewnia automatyczne skalowanie: jeśli obciążenie rośnie, Kubernetes sam uruchamia nowe kopie potrzebnej usługi.
Główne wyzwanie: Strefy czasowe
To cichy koszmar każdego globalnego projektu. Rozwiązanie jest jedno i nie podlega dyskusji: na backendzie wszystkie daty i czasy są przechowywane wyłącznie w UTC. Absolutnie wszystko. A już aplikacja kliencka odpowiada za konwersję na lokalny czas użytkownika. Jakiekolwiek inne podejście to gwarantowana katastrofa w przyszłości.
W rezultacie, moja praca to nie tylko „kodowanie funkcji”. To inżynieria skomplikowanego, odpornego na awarie i szybkiego systemu rozproszonego, który nie zawiedzie w godzinach szczytu, gdy tysiące ludzi na całym świecie naciskają przycisk „Rozpocznij lekcję”.