Django: monolit czy mikroserwisy? Przewodnik decyzyjny CTO

Praktyczny framework decyzji dla seniorów, leadów i CTO: kiedy Django powinno pozostać modularnym monolitem, a kiedy mikroserwisy naprawdę dają zwrot.

Krótka odpowiedź

Jeśli jesteś senior/lead/CTO i budujesz produkt w Django, decyzję ustaw domyślnie na modularny monolit.

Przechodź do mikroserwisów dopiero wtedy, gdy masz twarde dowody, że koszt koordynacji wewnątrz jednego repo i jednej bazy jest wyższy niż koszt systemu rozproszonego.

To nie jest decyzja technologiczna. To jest decyzja o koszcie zmian w perspektywie 12-24 miesięcy.

Najczęstszy błąd decyzyjny

Zespoły wybierają architekturę na podstawie skali ruchu, a nie na podstawie skali organizacji.

W praktyce większość problemów "musimy iść w mikroserwisy" to:

brak limitów odpowiedzialności w kodzie,
słaby kontrakt między modułami,
nieoptymalne zapytania i brak cache,
niski poziom obserwowalności.

To są problemy egzekucji inżynierskiej, nie dowód na konieczność rozbijania systemu.

Kiedy monolit wygrywa

Monolit jest lepszy, gdy przynajmniej 4 z poniższych punktów są prawdziwe:

jeden zespół (albo 2-3 zespoły) współdzieli roadmapę i release train,
domeny są silnie sprzężone transakcyjnie,
większość przypadków biznesowych wymaga atomowych zapisów,
nie masz dedykowanej platform team odpowiedzialnej za infrastrukturalny "produkt wewnętrzny",
on-call jest mały i nie ma pojemności na wzrost powierzchni awarii.

W Django możesz długo utrzymać wysoką przepustowość zmian przez:

modularny podział na apps z jasnymi kontraktami wejścia,
separację warstwy domenowej od transportu HTTP,
agresywną optymalizację odczytu (select_related, prefetch_related, cache warstwowy),
asynchroniczne ścieżki pracy (kolejki zadań) dla operacji niekrytycznych czasowo.

To często wystarcza, żeby odroczyć mikroserwisy o 12-18 miesięcy bez utraty tempa biznesowego.

Kiedy mikroserwisy dają realny ROI

Mikroserwisy mają sens, gdy spełniasz większość warunków:

masz wyraźne bounded contexts o niskim poziomie współdzielonych transakcji,
zespoły mają niezależne roadmapy i potrzebują niezależnych wdrożeń,
profile obciążenia między domenami różnią się mocno (np. katalog 10x read-heavy vs checkout write-heavy),
masz dojrzałe CI/CD, versioning kontraktów i automatyczne testy integracyjne,
masz ustandaryzowaną observability (metryki, logi, trace) i realny proces SLO/error budget.

Bez tych warunków mikroserwisy nie są "skalowaniem". Są mnożnikiem kosztu koordynacji.

Rygorystyczny model decyzji (7 kryteriów)

Użyj skali od -2 do +2 dla każdego kryterium:

-2 silnie za monolitem,
0 neutralnie,
+2 silnie za mikroserwisami.

Następnie policz wynik ważony.

Kryterium 1: Niezależność roadmap zespołów (waga 3)

-2: jeden wspólny backlog i wspólne releasy,
+2: 3+ zespoły z niezależnymi celami kwartalnymi.

Kryterium 2: Granice domen i transakcje (waga 3)

-2: wiele flow wymaga jednej transakcji SQL przez kilka obszarów,
+2: większość flow domyka się w obrębie jednego bounded context.

Kryterium 3: Różnice profilu ruchu (waga 2)

-2: obciążenie równomierne,
+2: wyraźnie różne profile i potrzeba niezależnego skalowania.

Kryterium 4: Dojrzałość platformy (waga 3)

-2: słaby pipeline, brak contract tests, ręczne release,
+2: automatyzacja end-to-end i rollback per service.

Kryterium 5: Observability i SRE readiness (waga 3)

-2: brak spójnego tracingu, brak SLO,
+2: telemetry standard, tracing cross-service, error budget policy.

Kryterium 6: Ownership i operacje (waga 2)

-2: brak jednoznacznych właścicieli domen,
+2: jasno przypisane ownerstwo usługi + rotacje on-call.

Kryterium 7: Koszt zmiany compliance/security (waga 2)

-2: centralne wymagania łatwiejsze do utrzymania w jednym miejscu,
+2: regulacje wymagają izolacji domen i osobnych granic dostępu.

Wzór

Wynik = suma(kryterium * waga)

Interpretacja:

wynik <= 5: zostań przy modularnym monolicie,
wynik 6-14: faza przejściowa, najpierw napraw platformę i kontrakty,
wynik >= 15: mikroserwisy uzasadnione biznesowo i operacyjnie.

Django: jak podnieść sufit modularnego monolitu

Zanim rozbijesz system, wykonaj ten zestaw działań:

1. Stabilne granice modułów

Każda aplikacja Django powinna mieć jawny interfejs warstwy domenowej. Widoki i taski nie powinny wołać bezpośrednio losowych modeli z innej domeny.

2. Odczyt i write path rozdzielone operacyjnie

Read-heavy endpointy optymalizuj osobno:

precyzyjne indeksy,
ograniczenie N+1,
cache key strategy z kontrolą invalidacji,
paginacja i limity payloadu.

3. Kolejki i idempotencja

Asynchroniczne operacje traktuj jako pierwszą linię skalowania procesowego, ale z idempotentnym handlerem i retry policy.

4. Bramy architektoniczne

Dodaj reguły statyczne i testy kontraktowe między modułami, żeby uniknąć "silent coupling".

Jeśli po tym nadal masz chroniczny problem lead time, dopiero wtedy rozważ ekstrakcję usługi.

Spójność danych: realny koszt mikroserwisów

W monolicie łatwo utrzymasz lokalne ACID i przewidywalne rollbacki.

W mikroserwisach szybko wchodzisz w sagi, kompensacje, kolejki zdarzeń i opóźnioną spójność. To działa, ale kosztuje:

więcej scenariuszy błędów,
trudniejsze debugowanie,
większy koszt testów integracyjnych,
więcej pracy on-call przy incydentach międzyserwisowych.

Dlatego "database per service" nie jest darmowym ulepszeniem. To inwestycja, która zwraca się tylko przy realnej autonomii domen.

Plan przejścia na 90 dni (bez hazardu architektonicznego)

Dni 1-30: Baseline

Ustal metryki bazowe: lead time, deployment frequency, MTTR, change failure rate.
Dodaj tracing end-to-end dla krytycznych ścieżek.
Zmapuj coupling między modułami i zależności transakcyjne.

Dni 31-60: Dekompozycja logiczna w monolicie

Wydziel granice domen wewnątrz repo.
Wprowadź kontrakty modułów i testy kontraktowe.
Ogranicz cross-module write.

Dni 61-90: Pilot jednej usługi

Wyciągnij tylko jedną domenę o wysokiej autonomii i czytelnym ownerstwie.
Ustal warunki sukcesu (np. krótszy lead time o 20%, brak wzrostu MTTR).
Jeśli warunki nie są spełnione, zatrzymaj rollout i wróć do optymalizacji monolitu.

Czerwone flagi (stop dla mikroserwisów)

"Potrzebujemy mikroserwisów, bo wszyscy tak robią".
Brak platform team i brak jednoznacznego ownerstwa usług.
Brak spójnego observability stack.
Silne transakcje cross-domain w core flow biznesowym.
Brak dyscypliny wersjonowania API i contract tests.

Finalny werdykt

Dla większości organizacji budujących produkt w Django właściwa kolejność to:

Modularny monolit z rygorem granic domen.
Twarde metryki przepływu i niezawodności.
Dopiero potem mikroserwisy, selektywnie i pilotowo.

Jeśli nie umiesz utrzymać porządku architektonicznego w monolicie, nie utrzymasz go także w systemie rozproszonym. Tam zapłacisz ten sam dług z odsetkami operacyjnymi.