Rapport architectuurreview

1. Managementsamenvatting

• Het systeem kan de huidige belasting aan, maar zodra het aantal klanten verdubbelt, worden rapportage en de orderflow naar verwachting een bottleneck.
• Het meest urgente risico zit bij beveiliging en continuïteit: de databaseback-ups zijn nooit getest door ze terug te zetten, en het adminpanel is voor iedereen bereikbaar.
• Opnieuw bouwen is niet nodig. De aanbevolen route is de bestaande monoliet op te splitsen in modules en hem in 6 maanden stap voor stap robuuster te maken.

2. Scope en aanpak

Duur

5 werkdagen

Onderzocht

Codebase van de hoofdapplicatie (~120.000 regels), databaseschema, server- en deployment-infrastructuur

Gesprekken

4 gesprekken met de tech lead, twee developers en de verantwoordelijke voor operations

Tools

Code review, queryplannen (EXPLAIN ANALYZE), dependency- en securityscans, loadprofiling

3. Bevindingen

Gerangschikt op impact en urgentie.

1. #1KritiekContinuïteitGeschatte inspanning: 1 dag

   Er wordt dagelijks een back-up gemaakt, maar die is nooit getest door hem terug te zetten; de back-ups staan op dezelfde server.

   Impact: Bij een defecte schijf gaan zowel de data als de back-ups verloren.

   Aanbeveling: Back-ups naar een aparte locatie verplaatsen en maandelijks een hersteltest doen.

2. #2KritiekBeveiligingGeschatte inspanning: 2 dagen

   Het adminpanel is vanaf internet bereikbaar, zonder tweefactorauthenticatie en zonder limiet op inlogpogingen.

   Impact: Met een brute-force-aanval is alle klantdata toegankelijk.

   Aanbeveling: Het panel achter een VPN of IP-beperking zetten en 2FA en rate limiting toevoegen.

3. #3HoogPerformanceGeschatte inspanning: 3 dagen

   De query voor het maandrapport scant een tabel zonder index van begin tot eind (gemiddeld 38 s).

   Impact: Terwijl het rapport draait, worden de orderschermen traag.

   Aanbeveling: Twee samengestelde indexen, en het rapport leest uit een overzichtstabel die ’s nachts wordt voorbereid.

4. #4HoogArchitectuurGeschatte inspanning: 4–6 weken

   De code voor orders, voorraad en facturatie schrijft rechtstreeks in elkaars tabellen.

   Impact: Een wijziging in de ene module breekt de andere; nieuwe features gaan steeds trager.

   Aanbeveling: Modulegrenzen trekken en alle communicatie tussen modules via één servicelaag laten lopen.

5. #5GemiddeldOnderhoudGeschatte inspanning: 2 weken

   Het framework loopt twee hoofdversies achter; 14 dependencies hebben bekende kwetsbaarheden.

   Impact: Security-updates kunnen niet worden doorgevoerd, en de upgrade wordt elke maand lastiger.

   Aanbeveling: Eerst de dependencies upgraden, daarna het framework versie voor versie.

6. #6GemiddeldTeamGeschatte inspanning: 2–3 weken

   De geautomatiseerde testdekking is 8%; deployment gaat handmatig en hangt af van één persoon.

   Impact: Als die persoon er niet is, kan er niets live; fouten worden door klanten ontdekt.

   Aanbeveling: E2E-tests voor de kritieke flows en een geautomatiseerde deployment-pipeline.

4. Doelarchitectuur

• Het blijft één applicatie (modulaire monoliet); orders, voorraad, facturatie en rapportage zijn aparte modules.
• Rapportage leest uit overzichtstabellen die de hoofddatabase niet belasten.
• Het adminpanel staat in het interne netwerk; deployment is geautomatiseerd en terug te draaien.

5. Migratieplan

1. Eerste 30 dagen

   Risico’s afdekken

   • Back-ups en hersteltest
   • Beveiliging van het adminpanel
   • Rapportquery versnellen

2. 1–3 maanden

   Fundament verstevigen

   • Upgrade van dependencies en framework
   • Tests voor de kritieke flows
   • Geautomatiseerde deployment-pipeline

3. 3–6 maanden

   Opsplitsen in modules

   • Order- en voorraadmodule loskoppelen
   • Facturatie naar de servicelaag verplaatsen
   • Architectuurdocumentatie en overdracht aan het team