AtlasWiki: multi-tenantowa baza wiedzy

Problem

Notion to miejsce, w którym wiedza firmy zamieszkuje na cudzych serwerach, za subskrypcją, o jedną zmianę cennika od projektu migracyjnego. Open-source’owe wiki albo wyglądają jak z 2008 roku, albo wymagają klastra Kubernetes i administratora na pół etatu. Luka: wiki, która wygląda nowocześnie, działa na jednej maszynie i traktuje izolację tenantów jako gwarancję bazy danych, a nie if-a w kodzie.

Co zbudowaliśmy

Multi-tenantową bazę wiedzy z doświadczeniem edycji, jakiego ludzie oczekują po Notion: edytor WYSIWYG na TipTap ze slash commands, zagnieżdżonymi stronami, backlinkami i osadzeniami inline, na architekturze, która izolację bierze śmiertelnie poważnie.

• Row-level security jako granica izolacji. Separację tenantów wymuszają polityki RLS w PostgreSQL, nie kod aplikacji. Zapomniany WHERE w jakimś przyszłym endpoincie nie wycieknie stron innego tenanta, bo baza po prostu odmówi ich zwrócenia.
• Załączniki jako usługa. Pliki dołączane do stron w ogóle nie są przechowywane przez wiki. Idą przez wewnętrzne API naszej self-hosted platformy plikowej po prywatnej sieci kontenerów: jedna płaszczyzna storage, spójne backupy, zero zduplikowanego kodu uploadu.
• Szybkość z architektury, nie z tuningu. Renderowane serwerowo szkielety stron, odchudzone payloady API, agresywne indeksowanie. Ładowanie poniżej 100 ms na mini PC, bez żadnego CDN.

Architektura

FastAPI, React, PostgreSQL z RLS, wdrożone jako kontenery za reverse proxy Traefik z TLS i nagłówkami bezpieczeństwa. Wywołania service-to-service jadą po wewnętrznej sieci Dockera, która nigdy nie jest wystawiona publicznie.

Efekt

Baza wiedzy, która nie kosztuje nic miesięcznie, ładuje się szybciej niż SaaS, którego zastąpiła, i demonstruje wzorzec bezpieczeństwa, który dziś reużywamy wszędzie: zepchnij gwarancje izolacji do bazy, integruj usługi po prywatnych sieciach i pozwól każdej platformie robić dobrze jedną rzecz.