Bij het ontwerpen van de interactie tussen microservices komt vaak de vraag naar voren over de implementatie van gedistribueerde transacties. In monolithen zijn de ingebouwde mechanismen vaak voldoende, maar in microservices is de situatie gecompliceerder door verschillende databases, technologieën en gegevenswisselformaten. De belangrijkste regel is om lange gedistribueerde transacties te vermijden, omdat deze slecht schaalbaar zijn en het risico van prestatieverlies met zich meebrengen.
In plaats van klassieke ACID-protocollen wordt aanbevolen om het SAGA-patroon te gebruiken. Dit is een keten van lokale transacties, waarbij elke microservice zijn wijzigingen vastlegt en, indien nodig voor een terugdraaiing, een compensatieoperatie binnen zijn verantwoordelijkheid verstuurt.
Een voorbeeld van een vereenvoudigde implementatie van saga-beheer in Node.js met REST:
// Saga orchestrator op Express app.post('/saga', async (req, res) => { try { await serviceA.transaction(); await serviceB.transaction(); res.send('ok'); } catch (err) { await serviceA.rollback(); res.status(500).send('rollback uitgevoerd'); } });
Kernpunten:
Kun je klassieke two-phase commits (2PC) tussen microservices gebruiken voor transactieondersteuning?
Ja, maar dit wordt niet aanbevolen voor microservicesarchitecturen. 2PC vertraagt de schaalbaarheid en verbindt services technologisch en organisatorisch.
Zijn alle SAGA-scenario's geschikt voor financiële transacties?
Nee. SAGA is moeilijker correct te implementeren voor scenario's waarbij strikte ACID-normen noodzakelijk zijn, zoals de berekening van saldi op één rekening. Het is belangrijk om risico's te beoordelen en een compromis te kiezen.
Hoe wordt de verwerking van een mislukte tussenstap afgehandeld als een microservice niet kan terugdraaien?
In dergelijke gevallen moet een handmatig of geautomatiseerd compensatieprotocol worden geïmplementeerd, mogelijk met behulp van een apart logboek van gebeurtenissen.