Waarom de saaie beslissingen mijn beste beslissingen waren
Ik dacht vroeger dat een goede developer zijn betekende dat je complexe code schreef.
Ik zat ernaast.
Tijdens het ontwerpen van een MVP voor een medische kliniek die uiteindelijk een multi-tenant SaaS zal worden, leerde ik een harde les. De code is het makkelijke deel. Het moeilijke deel is beslissen wat je NIET moet bouwen.
De verleiding was groot om microservices, events en Kubernetes te gebruiken. Dat ziet er geweldig uit op een CV. Maar microservices brengen hoge kosten met zich mee. Je betaalt ervoor met complexe pipelines, versiebeheerproblemen en lastige debugging.
Met een team van drie personen en weinig gebruikers zijn microservices gewoon extra werk. Je lost problemen op die je nog niet hebt.
In plaats daarvan koos ik voor een eenvoudige gelaagde architectuur met .NET 8 en PostgreSQL. Dat kost ongeveer $30 per maand.
Ik richtte me op slimme, goedkope beslissingen die later duur zijn om te veranderen:
• Vanaf dag één een TenantId-kolom aan elke tabel toegevoegd. • Docker gebruikt vanaf de eerste commit. • Een interface gemaakt voor de WhatsApp-provider.
Dit kostte elk een middag. Het veranderde toekomstige migraties in eenvoudige configuratiewijzigingen.
Ik leerde ook om patronen af te stemmen op de zakelijke behoeften.
Zo gebruikte ik bijvoorbeeld het Outbox-patroon voor WhatsApp-notificaties. Het boeken van een afspraak moet snel en betrouwbaar zijn. Het versturen van een bericht kan twee seconden later gebeuren. Als WhatsApp traag is, werkt de afspraak nog steeds.
Ik wees echter "eventual consistency" af voor medische dossiers. Een medische diagnose moet accuraat en onmiddellijk zijn. In de gezondheidszorg zijn juridische vereisten in feite architecturale vereisten.
Ik heb ook naar de echte cijfers gekeken.
Een Kubernetes-setup (EKS) zou $545 tot $615 per maand kosten. Een AWS Fargate-setup kost $350 tot $420 per maand.
Dat is een besparing van meer dan $150 per maand. Ik koos voor Fargate omdat het eenvoudiger en goedkoper is voor onze huidige omvang.
Mijn strategie is simpel:
- Gebruik eerst lagen.
- Gebruik events wanneer externe afhankelijkheden (zoals WhatsApp) je systeem gaan beïnvloeden.
- Stap pas over op microservices wanneer het volume en de teamgrootte dit vereisen.
Ontwerp niet voor twintig klanten die je nog niet hebt. Bouw voor de klant die je vandaag betaalt.