Veerkrachtpatronen
Elke afhankelijkheid valt ooit uit. Veerkrachtpatronen bepalen of dat een rimpeling wordt of een storing.
Een circuit breaker aan het werk
Gesloten
Oproepen gaan door en fouten worden geteld.
Open
Oproepen falen meteen met een fallback; de service krijgt tijd om te herstellen.
Halfopen
Eén testoproep beslist: succes sluit de breaker, een fout opent hem opnieuw.
Circuit Breaker
Voorkom kettingreacties van storingen door oproepen naar falende services te stoppen. Zodra het aantal fouten een drempel overschrijdt, gaat het circuit "open" en falen verzoeken meteen. Test periodiek of de service hersteld is (halfopen toestand).
Retry-patroon
Mislukte bewerkingen automatisch opnieuw proberen met exponentiële backoff. Nuttig bij tijdelijke fouten (netwerkhaperingen, tijdelijke onbeschikbaarheid). Voorzie een maximumaantal pogingen en zorg voor idempotentie.
Bulkhead-patroon
Isoleer resources (connection pools, threads) zodat een storing in één deel niet alle resources opslorpt. Vergelijkbaar met de waterdichte compartimenten in een schip.
Integratiepatronen
API Gateway-patroon
Eén toegangspunt voor alle clientverzoeken. De gateway routeert, transformeert en bundelt verzoeken naar de backendservices.
- Voordelen: Eenvoudigere clientcode, centrale beveiliging, transformatie van verzoeken en antwoorden
- Implementatie: Azure API Management, Application Gateway, een eigen gateway met Ocelot
Backends for Frontends (BFF): een backend per frontend
Aparte backendservices, geoptimaliseerd voor elke frontend (web, mobiel, IoT).
- Voordelen: Antwoorden op maat, onafhankelijke evolutie, betere performantie
- Toepassingen: Multiplatformapplicaties met verschillende UX-vereisten
Strangler fig-patroon
Legacysystemen stapsgewijs migreren door verzoeken naar nieuwe services te routeren en de oude functionaliteit geleidelijk te vervangen.
- Voordelen: Modernisering met laag risico, parallelle werking, geleidelijke validatie
- Implementatie: Een routeringslaag (API-gateway) stuurt het verkeer op basis van feature flags
Patronen voor gegevensbeheer
Database per service
Elke microservice beheert zijn eigen database. Geen gedeelde databases tussen services. Gegevens worden gesynchroniseerd via events of API's.
CQRS (Command Query Responsibility Segregation)
Aparte modellen voor lezen en schrijven. Het schrijfmodel is geoptimaliseerd voor consistentie, de leesmodellen zijn gedenormaliseerd voor snelle query's.
Implementatie: SQL voor writes, Cosmos DB voor reads, Event Grid voor synchronisatie
Saga-patroon
Beheer gedistribueerde transacties over microservices heen met compenserende transacties. Via orkestratie (centrale coördinator) of choreografie (event-driven).