Vladimir Ilmenev

Zaproponuj Vladimir pracę nad swoim kolejnym zleceniem.

Ałmaty (Alma-Ata), Kazachstan

7 miesięcy 30 dni temu

gotowy do podjęcia pracy

w Serwisie 8 miesięcy 13 dni

Ranking

Zakończonych zleceń

Średnia ocena

Ranking

Portfolio

16 934 PLN
full-stack rozwój

Programowanie stron internetowych

Krok 1: Architektura. Prędkość ponad wszystko.
Nie ma tutaj skomplikowanej logiki interakcji między tysiącami użytkowników, więc tworzenie zoo mikroserwisów byłoby nadmiernym inżynierowaniem. Wybrałbym dobrze zorganizowany monolit lub architekturę z kilkoma dużymi serwisami („makroserwisy”). Na przykład:

Core API: Główne jądro, które zwraca dane słownika.
…
Users API: Serwis do zarządzania użytkownikami, ich osobistymi słownikami i postępami w ćwiczeniach.

Takie podejście upraszcza rozwój i wdrażanie, a w projekcie, w którym 95% zapytań to anonimowe zapytania wyszukiwania, jest więcej niż uzasadnione.

Krok 2: Serce systemu — wyszukiwanie
Zwykła relacyjna baza danych (jak MySQL/PostgreSQL) umrze na zapytaniach wyszukiwania w słowniku. Wykonywanie SELECT * FROM words WHERE word LIKE '...%' na tabeli z dziesiątkami milionów rekordów to samobójstwo.

Dlatego jądro systemu to połączenie dwóch narzędzi:

PostgreSQL: Jako główne, niezawodne repozytorium. Tutaj znajduje się „surowy” słownik ze wszystkimi powiązaniami, formami słów, przykładami. To nasze źródło prawdy.

Elasticsearch: Specjalizowany silnik wyszukiwania. Wszystkie dane z PostgreSQL są indeksowane w Elasticsearch.

Jak to działa:
Kiedy użytkownik wpisuje słowo w wyszukiwarce, zapytanie nie trafia do bazy, lecz do Elasticsearch. Ten w milisekundy znajduje odpowiednie artykuły, poprawia literówki, dobiera odpowiednie wyniki i zwraca ich ID. I dopiero potem nasz backend z tymi ID idzie do PostgreSQL (lub, co jeszcze lepsze, do cache) po pełne dane artykułu słownikowego i zwraca je użytkownikowi. To zapewnia błyskawiczną prędkość wyszukiwania.

Krok 3: Pipeline danych i caching
Baza słownikowa to ogromna masa danych. Muszą być skądś pobierane, przetwarzane i przygotowywane do użycia. Zbudowałbym pipeline treści:

Napisałbym skrypty-parsery, które potrafią „czytać” różne formaty słownikowe (na przykład, DSL, StarDict).

Te skrypty przetwarzają dane, przekształcają je do jednolitej struktury i ładują do naszej głównej bazy PostgreSQL.

Po załadowaniu uruchamiany jest proces indeksacji w Elasticsearch.

Caching tutaj to król. 90% użytkowników szuka tych samych popularnych słów. Nie ma sensu za każdym razem sięgać do bazy.

Redis jest używany do agresywnego cachowania. Poproszono o słowo „hello”? Oddaliśmy wynik z Elasticsearch/PostgreSQL i od razu zapisaliśmy go w Redis na kilka godzin. Następny użytkownik, szukający „hello”, otrzyma odpowiedź z superszybkiej pamięci operacyjnej w ułamku milisekundy.

Pliki audio z wymową, zdjęcia i inne statyczne zasoby, oczywiście, nie są zwracane z serwera aplikacji. Są ładowane na CDN (Content Delivery Network) i dystrybuowane z najbliższego serwera do użytkownika na całym świecie.

Krok 4: Funkcje użytkownika
Osobiste słowniki i ćwiczenia to klasyczna funkcjonalność CRUD. Tutaj doskonale sprawdza się PostgreSQL.

Osobisty słownik: Prosta tabela user_saved_words z relacją „wiele-do-wielu” między użytkownikami a słowami.

Ćwiczenia: Logika backendu, która pobiera słowa z osobistego słownika użytkownika, generuje warianty odpowiedzi (niepoprawne warianty można brać z podobnych pod względem pisowni lub znaczenia słów) i wysyła na frontend w postaci obiektu JSON do treningu.

Stos technologiczny
Język: Python (Django/FastAPI) lub PHP (Symfony/Laravel). Oba idealnie nadają się do projektów treściowych i szybkiego rozwoju API.

Bazy danych: PostgreSQL (źródło prawdy), Elasticsearch (wyszukiwanie), Redis (cache).

Infrastruktura: Docker do konteneryzacji. Aplikacja jest wdrożona na kilku wirtualnych serwerach za Nginx jako load balancer. Prosto, niezawodnie i efektywnie dla tego typu projektu.

W rezultacie praca nad WooordHunt to nie kwestia skomplikowanej logiki biznesowej, ale inżynieryjnej elegancji. To tworzenie wysokowydajnego systemu, zoptymalizowanego do odczytu danych. Celem jest wyciśnięcie maksimum prędkości z sprzętu i oprogramowania, aby doświadczenie użytkownika było płynne i natychmiastowe.
25 442 PLN
programista-backend

Python

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ę”.