Lätt att skala

Vi vet att tätt kopplade system är ömtåliga system. Mikro-moduler eller tjänstebaserad struktur används även om det är en monolit. Gruppering görs efter funktioner/domäner, inte tekniska lager (Domain-Driven Design lite). Frontend/backend är avkopplade via API-kontrakt (OpenAPI, GraphQL). Fördelar: Lätt att isolera, skala eller ersätta moduler utan att bryta hela systemet.

Vi väljer skalbara universella körningar (främst Node.js) för backend. PostgreSQL, moln PostgreSQL-kompatibla databaser, Supabase, Firebase används vid behov. Redis integreras för tung läsningstrafik eller caching. Moln-native infrastruktur och docker används: AWS / GCP / — med autoskalningsstöd. Otydliga verktyg som inte kan skalas horisontellt eller saknar samhällsstöd undviks.

Vi vet att allt inte behöver hända i realtid. Långvariga eller bakgrundsuppgifter (e-post, bildbehandling, fakturering) avlastas till köer, etc. Exempel: Efter att en användare registrerat sig, behandlas fakturering/e-post i bakgrunden, inte inline. Detta hjälper till för bättre prestanda och skalbarhet.

Vi vet att dålig schema = framtida omarbete. Versionerade API:er (/api/v1/...) används för att förhindra att klienter bryts. UUID:er föredras framför inkrementella ID:n (t.ex. för att slå samman data över regioner). Multi-tenancy planeras för (särskilt i SaaS): Radnivå vs schema-nivå separation, lägg till tenant_id tidigt.

Vi vet att du inte kan skala det du inte kan se. Verktyg som Sentry används för frontend-felspårning; Prometheus för backend/infrastrukturobservabilitet; PostHog, Google Analytics för produktanalys; Kontinuerliga kontroller för övervakning av driftstopp. Larm (Slack/e-post) är inställda för krascher, köbackloggar, DB-spikar, etc.

Vi vet att monoliter kan skalas, men stateless tjänster skalar bättre. Att lagra användarsessioner i lokal minne undviks — Redis/sessionlagring används. Servrar görs stateless så att de enkelt kan dupliceras. Containerisering används: Docker + orkestratorer (molnleverantörer). Detta möjliggör autoskalning utan klibbiga sessioner eller flaskhalsar i delat minne.

Vi vet att fler användare = större attackyta. RBAC/ABAC-mönster (rollbaserad åtkomstkontroll) är inställda. Hastighetsbegränsning, indata validering och säkerhetsrubriker tillämpas. Hemligheter förvaras i valv och roteras.

API-lager: Hastighetsbegränsning, paginering, GraphQL-federation (om det behövs) implementeras. Frontend: Lazy loading, CDN-hosting, kodsplittring används. Autoskalning används. Databas: Indexer omindexeras, sharding planeras om det behövs, och så vidare.