Pierwsza wersja SaaS rzadko przegrywa dlatego, że ma zbyt mało funkcji. Częściej problemem jest architektura, która nie przewidziała drugiego typu klienta, nowego modelu rozliczeń albo integracji wymaganej przez większą firmę. Ten poradnik architektury aplikacji SaaS pokazuje, jak podejmować decyzje techniczne tak, aby produkt mógł rosnąć bez niepotrzebnego przepisywania całego systemu.
Dobra architektura nie oznacza najbardziej złożonego stosu technologicznego. Ma wspierać konkretny model biznesowy: sposób pozyskiwania klientów, zakres planów abonamentowych, wymagania bezpieczeństwa i tempo rozwoju. Dla startupu budującego MVP właściwa decyzja może wyglądać inaczej niż dla firmy przenoszącej wewnętrzny proces do modelu abonamentowego.
Poradnik architektury aplikacji SaaS: zacznij od modelu produktu
Zanim zespół wybierze framework, bazę danych czy dostawcę chmury, powinien odpowiedzieć na kilka pytań produktowych. Kto jest tenantem, czyli podmiotem korzystającym z systemu? Czy będzie nim pojedyncza osoba, firma, oddział, a może organizacja z wieloma zespołami? Czy użytkownik może należeć do kilku organizacji? Jakie dane są wspólne, a jakie muszą pozostać odseparowane?
Te odpowiedzi wpływają na model danych, uprawnienia i przyszłą administrację. Przykładowo system dla biur rachunkowych może obsługiwać jedno konto organizacji i wielu klientów końcowych. Aplikacja do zarządzania sprzedażą może z kolei wymagać struktur: firma, dział, zespół, użytkownik oraz role przypisane na różnych poziomach. Uproszczenie tego modelu na starcie często kończy się kosztowną migracją po pierwszych wdrożeniach B2B.
Warto też rozdzielić trzy pojęcia: funkcję, plan cenowy i uprawnienie. Funkcja to np. eksport danych. Plan cenowy określa, czy klient może z niej korzystać. Uprawnienie decyduje, czy konkretny użytkownik w organizacji może wykonać eksport. Gdy te warstwy są wymieszane w kodzie, zmiana oferty handlowej zaczyna wymagać zmian programistycznych.
Wybierz granice modułów, zanim powstanie monolit funkcji
Na początku większość aplikacji SaaS może działać jako modularny monolit. To jedno wdrożenie i jeden spójny kod aplikacji, ale z jasno wydzielonymi obszarami odpowiedzialności. W praktyce modułami mogą być konto i tożsamość, organizacje, rozliczenia, główny proces biznesowy, powiadomienia, raportowanie oraz integracje.
To rozwiązanie jest zwykle szybsze i tańsze od mikroserwisów. Ułatwia pracę małemu zespołowi, ogranicza liczbę środowisk i pozwala szybciej weryfikować założenia rynkowe. Warunek jest jeden: moduły nie mogą komunikować się przez przypadkowe odwołania do dowolnych fragmentów bazy danych. Każdy powinien mieć określony zakres odpowiedzialności oraz czytelny interfejs dla pozostałej części aplikacji.
Mikroserwisy mają sens, gdy występuje realna potrzeba niezależnego skalowania, osobnych cykli wdrożeń albo wyraźnego podziału pracy pomiędzy większe zespoły. Przykładem może być intensywnie obciążany moduł analityczny lub silnik przetwarzający pliki, który nie powinien wpływać na działanie panelu klienta. Wdrożenie mikroserwisów tylko dlatego, że są popularne, zwiększa koszt obserwowalności, testów, komunikacji między usługami i utrzymania infrastruktury.
Projektuj API wokół procesów biznesowych
API nie powinno być prostym odbiciem tabel w bazie. Endpointy i kontrakty powinny opisywać działania, które użytkownik lub inny system rzeczywiście wykonuje: utwórz projekt, zaproś członka zespołu, wygeneruj raport, aktywuj subskrypcję. Taki model jest łatwiejszy do utrzymania, gdy pojawia się aplikacja mobilna, panel partnera lub integracja z systemem klienta.
Warto od początku wersjonować istotne kontrakty API i dokumentować błędy zwracane przez system. Nie chodzi o rozbudowaną formalność, lecz o ochronę przed sytuacją, w której jedna zmiana w backendzie zatrzymuje aplikację webową albo automatyzację po stronie klienta.
Dane tenantów: izolacja zależna od ryzyka i skali
W SaaS dane różnych klientów muszą być od siebie logicznie oddzielone. Najczęściej stosuje się trzy modele: wspólną bazę i wspólne tabele z identyfikatorem tenanta, osobny schemat dla każdego tenanta albo osobną bazę danych dla każdego klienta.
Wspólne tabele są rozsądnym wyborem dla wielu produktów na etapie MVP i wzrostu. Upraszczają migracje, raportowanie oraz koszty infrastruktury. Wymagają jednak konsekwencji: identyfikator organizacji musi być uwzględniony w każdym zapytaniu, indeksie, polityce dostępu i teście. Jeden błąd w filtrze może prowadzić do wyświetlenia danych niewłaściwego klienta.
Osobne bazy dają mocniejszą izolację i mogą być wymagane przez klientów korporacyjnych, regulacje branżowe lub indywidualne umowy. Jednocześnie podnoszą koszt operacyjny. Aktualizacje schematów, backupy, monitoring i raporty przekrojowe stają się bardziej złożone. Dobrym kompromisem bywa rozpoczęcie od współdzielonej architektury z możliwością wydzielenia strategicznych klientów w późniejszym etapie.
Nie zapisuj samego `tenant_id` tylko w warstwie interfejsu. Kontekst organizacji powinien być ustalany na podstawie bezpiecznie zweryfikowanej sesji i przekazywany przez całą warstwę aplikacji. W bazie warto stosować ograniczenia, klucze obce oraz, tam gdzie technologia na to pozwala, polityki dostępu na poziomie wiersza.
Tożsamość, role i audyt nie są dodatkiem
Logowanie to tylko fragment obszaru bezpieczeństwa. Aplikacja SaaS potrzebuje mechanizmu zarządzania sesją, odzyskiwania dostępu, weryfikacji adresu e-mail, obsługi zaproszeń oraz kontroli ról. W przypadku klientów biznesowych szybko pojawiają się pytania o logowanie przez firmowego dostawcę tożsamości, uwierzytelnianie wieloskładnikowe i możliwość odebrania dostępu pracownikowi bez usuwania danych.
Najprostszy model ról typu administrator, członek i odczyt wystarczy w wielu MVP. Jeśli jednak produkt obsługuje procesy finansowe, medyczne lub operacyjne, lepiej projektować uprawnienia jako zestaw konkretnych akcji. Pozwala to dodać niestandardową rolę bez mnożenia wyjątków w kodzie.
Równie istotny jest audyt. Zapisuj, kto i kiedy zmienił ważne dane, wyeksportował informacje, zmodyfikował role lub skonfigurował integrację. Dziennik audytowy pomaga w obsłudze incydentów, ale ma też konkretną wartość handlową podczas rozmów z większym klientem.
Rozliczenia traktuj jako niezależny obszar domenowy
Subskrypcje są bardziej złożone, niż sugeruje ekran płatności. System musi obsłużyć aktywację, okres próbny, zmianę planu, limit użytkowników lub zużycia, nieudaną płatność, faktury, anulowanie oraz dostęp po zakończeniu abonamentu. W Polsce dochodzą jeszcze kwestie księgowe i oczekiwania dotyczące dokumentów sprzedażowych.
Nie uzależniaj dostępu do produktu wyłącznie od statusu jednej transakcji. Lepiej utrzymywać własny stan subskrypcji, a zdarzenia od operatora płatności przetwarzać jako komunikaty zewnętrzne. Takie zdarzenia mogą dotrzeć z opóźnieniem, pojawić się ponownie albo nie dotrzeć chwilowo z powodu błędu sieci. Przetwarzanie musi być idempotentne, czyli bezpieczne przy wielokrotnym odebraniu tego samego komunikatu.
Model limitów także wymaga decyzji. Część produktów ogranicza liczbę użytkowników, inne liczbę projektów, dokumentów, wysłanych wiadomości albo zużycie API. Limit powinien być liczony w jednym, wiarygodnym miejscu po stronie backendu. Blokada oparta wyłącznie na komunikacie w interfejsie nie chroni systemu ani przychodu.
Skalowanie zaczyna się od pomiaru
Nie trzeba przewidywać miliona użytkowników przed premierą. Trzeba natomiast wiedzieć, co mierzyć od pierwszego dnia. Podstawą są błędy aplikacji, czas odpowiedzi kluczowych operacji, zużycie zasobów, liczba zadań w kolejce, stan integracji oraz aktywność na poziomie tenanta. Bez tych danych trudno odróżnić problem techniczny od nietrafionego procesu użytkownika.
Operacje, które mogą trwać długo, warto przenosić do kolejki zadań. Generowanie raportów, wysyłka większej liczby wiadomości, import plików czy synchronizacja z zewnętrznym systemem nie powinny blokować żądania użytkownika. Interfejs może potwierdzić przyjęcie zadania, a po zakończeniu poinformować o wyniku.
Cache przyspiesza produkt, ale może utrudniać poprawność danych. Stosuj go przede wszystkim dla odczytów powtarzalnych i kosztownych obliczeniowo, z określoną strategią wygaszania. W procesach, gdzie aktualność jest krytyczna, jak limity planu czy uprawnienia, lepiej stawiać na wiarygodne źródło danych niż pozorną szybkość.
Jak przełożyć architekturę na plan wdrożenia
Najbezpieczniejsza ścieżka to zbudowanie najpierw pionowego wycinka produktu. Powinien obejmować rejestrację organizacji, role, główny proces biznesowy, podstawową administrację i pierwszy wariant rozliczenia. Dzięki temu sprawdzasz pełny przepływ wartości, zamiast tworzyć oderwane moduły, które dopiero później trzeba połączyć.
Następnie rozwijaj architekturę zgodnie z potwierdzonym popytem. Gdy klienci potrzebują integracji, przygotuj warstwę zdarzeń i stabilne API. Gdy rośnie liczba użytkowników, inwestuj w monitoring, kolejki i optymalizację zapytań. Gdy sprzedaż kieruje produkt do większych organizacji, rozbuduj SSO, audyt oraz opcje izolacji danych.
W Frontfolks architekturę dedykowanej aplikacji warto omawiać już na etapie wyceny, ponieważ decyzje dotyczące tenantów, ról i integracji bezpośrednio wpływają na zakres oraz koszt wdrożenia. Dobrze przygotowany fundament nie ma imponować diagramem. Ma pozwalać szybciej sprzedawać, bezpiecznie obsługiwać klientów i rozwijać produkt wtedy, gdy biznes daje ku temu realny powód.