Problem
Użytkownicy pracujący w wielojęzycznym środowisku musieli tłumaczyć treści zgłoszeń i komentarzy, kopiując je do zewnętrznych narzędzi. Było to wolne, niewygodne i ryzykowne — dane biznesowe opuszczały kontrolowane środowisko, a proces rozbijał pracę na wiele kroków.
Kontekst
Rozwiązanie powstało jako rozszerzenie platformy ticketowej (Jira Data Center) w organizacji enterprise, z twardymi wymaganiami dotyczącymi bezpieczeństwa sekretów i braku wycieku danych do niekontrolowanych usług. Celem było tłumaczenie „w miejscu pracy“, bez opuszczania Jira.
Wymagania
- Tłumaczenie wybranych pól zgłoszenia i komentarzy bez wychodzenia z Jira.
- Sekrety (klucze, dane dostępowe) nigdy w kodzie pluginu ani po stronie klienta.
- Obsługa dużych treści i wielu równoległych żądań bez blokowania UI.
- Kontrolowany, audytowalny przepływ do usługi modelowej.
Rola
Zaprojektowałem całość rozwiązania i zaimplementowałem jego kluczowe elementy: plugin tłumaczący w Jira, współdzieloną warstwę bezpiecznej integracji (bridge + sekrety) oraz backend serverless w AWS z integracją z modelem językowym.
Architektura
Rozwiązanie celowo rozdziela odpowiedzialności: UI i logika domenowa w Jira, izolacja sekretów w osobnym pluginie bridge, a ciężka logika i dostęp do modelu w warstwie serverless.
Technologie
Plugin Jira (Java, Active Objects) dla UI, konfiguracji i uprawnień; osobny plugin bridge z lokalnym magazynem sekretów (PKCS12) i serwisem wywołań; AWS API Gateway + dwie Lambdy (autoryzacja i logika) + Amazon Bedrock; sekrety w IAM/Secrets Manager zamiast w kodzie.
Decyzje projektowe
- Rozdzielenie pluginów: osobny plugin bridge jako współdzielona warstwa bezpieczeństwa dla wielu integracji, zamiast wbudowywania sekretów w każdy plugin.
- Thin backend nad zarządzanym AI: logika tłumaczenia jako cienka warstwa serverless, model jako usługa zarządzana (Bedrock).
- Autoryzacja oddzielona od logiki: osobny authorizer przy API Gateway.
Trade-offy
- Więcej komponentów (plugin + bridge + serverless) = większa złożoność wdrożenia, ale znacznie mniejsza powierzchnia ryzyka i lepsza reużywalność.
- Zarządzany model (Bedrock) = szybszy start i brak utrzymania modelu, kosztem zależności od dostawcy i limitów usługi.
Problemy techniczne
- Duże treści przekraczały limity pojedynczego żądania do modelu.
- Wiele równoległych tłumaczeń groziło przeciążeniem usługi i blokowaniem UI.
- Konieczność zachowania kolejności i spójności fragmentów po stronie wyniku.
Rozwiązania
- Chunkowanie dużych payloadów i składanie wyniku z zachowaniem kolejności.
- Przetwarzanie asynchroniczne / wielowątkowe z kolejkowaniem i kontrolą liczby równoległych operacji (limit współbieżności), aby nie przeciążać usługi modelowej.
- Nieblokujący przepływ w UI — użytkownik nie czeka na całość synchronicznie.
Rezultat
Tłumaczenie stało się dostępne bezpośrednio w Jira, bez kopiowania danych do zewnętrznych narzędzi. Sekrety pozostały poza kodem i poza klientem, a architektura serverless pozwoliła skalować obsługę żądań bez utrzymywania własnej infrastruktury modelowej.
Lessons learned
- Wydzielenie warstwy sekretów jako osobnego komponentu opłaca się przy więcej niż jednej integracji.
- Kontrola współbieżności jest równie ważna jak sama integracja z modelem — bez niej „działa na jednym“, „pada na dziesięciu“.
What I’d do differently today
- Dodałbym warstwę cache dla powtarzalnych tłumaczeń oraz metryki kosztu/tokenów per żądanie.
- Rozważyłbym kolejkę zarządzaną (np. SQS) zamiast własnego kolejkowania w aplikacji.
Interview talking points
- Dlaczego sekrety trafiły do osobnego pluginu bridge, a nie do pluginu tłumaczącego.
- Jak chunkowanie + limit współbieżności chronią zarówno UX, jak i usługę modelową.
- Kompromis „thin serverless backend nad zarządzanym AI“ vs. własny hosting modelu.