Eenvoudig Schaalbaar

We weten dat strak gekoppelde systemen fragiele systemen zijn. Micro-modules of een service-gebaseerde structuur worden gebruikt, zelfs als het een monolith is. Groepering gebeurt op basis van functies/domeinen, niet op technische lagen (Domain-Driven Design lite). Frontend/backend zijn ontkoppeld via API-contracten (OpenAPI, GraphQL). Voordelen: Gemakkelijk om modules te isoleren, schalen of vervangen zonder het hele systeem te breken.

We kiezen voor schaalbare alomtegenwoordige runtimes (voornamelijk Node.js) voor de backend. PostgreSQL, cloud PostgreSQL compatibele DB's, Supabase, Firebase worden gebruikt indien nodig. Redis wordt geïntegreerd voor zware leesverkeer of caching. Cloud-native infrastructuur en Docker worden gebruikt: AWS / GCP / — met autoscaling ondersteuning. Obscure tools die niet horizontaal kunnen schalen of gebrek aan community-ondersteuning hebben, worden vermeden.

We weten dat niet alles in real-time hoeft te gebeuren. Langdurige of achtergrondtaken (e-mails, beeldverwerking, facturering) worden uitbesteed aan queues, enz. Voorbeeld: Nadat een gebruiker zich heeft aangemeld, wordt de facturering/e-mail op de achtergrond verwerkt, niet inline. Dit helpt voor betere prestaties en schaalbaarheid.

We weten dat een slecht schema = toekomstige herwerking. Versiebeheerde API's (/api/v1/...) worden gebruikt om te voorkomen dat clients worden gebroken. UUID's hebben de voorkeur boven incrementele ID's (bijv. voor het samenvoegen van gegevens over regio's). Multi-tenancy is gepland (vooral in SaaS): Rij-niveau versus schema-niveau scheiding, voeg tenant_id vroeg toe.

We weten dat je niet kunt schalen wat je niet kunt zien. Tools zoals Sentry worden gebruikt voor frontend foutopsporing; Prometheus voor backend/infrastructuur observability; PostHog, Google Analytics voor productanalyse; Voortdurende controles voor downtime monitoring. Alerts (Slack/e-mail) zijn ingesteld voor crashes, wachtrijachterstanden, DB-pieken, enz.

We weten dat monolithen kunnen schalen, maar stateless services schalen beter. Het opslaan van gebruikerssessies in lokaal geheugen wordt vermeden — Redis/sessieopslag wordt gebruikt. Servers worden stateless gemaakt zodat ze gemakkelijk kunnen worden gedupliceerd. Containerisatie wordt gebruikt: Docker + orchestrators (cloudproviders). Dit maakt autoscaling mogelijk zonder sticky sessions of gedeelde geheugenflessenhalzen.

We weten dat meer gebruikers = meer aanvalsvlak. RBAC/ABAC-patronen (role-based access control) zijn ingesteld. Rate limiting, invoervalidatie en beveiligingsheaders worden toegepast. Geheimen worden bewaard in kluizen en regelmatig vernieuwd.

API Laag: Rate limiting, paginering, GraphQL federatie (indien nodig) zijn geïmplementeerd. Frontend: Lazy loading, CDN-hosting, code splitting worden gebruikt. Autoscaling wordt toegepast. Database: Indexen worden opnieuw geïndexeerd, sharding is gepland indien nodig, enzovoort.