Saga pattern

Gestire le transazioni tra microservizi diversi

About me

• Scrivo (e leggo) codice da una quindicina d'anni
• Appassionato di FLOSS
• Allenatore di calcio giovanile
• Former:
  • Developer Advocate @ Google
  • Prof
  • Conference speaker
• Current:
  • Lead developer @ Brandon Group
  • Maintainer di MockK

"a software design pattern is a general, reusable solution to a commonly occurring problem within a given context"

(Wikipedia)

Il problema

Il problema (cont.)

• "Brandon group" in realtà è un set di (micro) servizi diversi
• Lo stato di un ordine dipende da una serie di transazioni compiute tra microservizi differenti ed entità esterne differenti
• Le transazioni possono non essere istantanee nè sincrone

La soluzione facile

Tuttavia...

Introducing, i concetti fondamentali:

Saga

• Una sequenza di passi, ognuno dei quali è una transazione locale di un microservizio

• Il cavaliere d'oro che presiede la casa dei Gemelli

Problema

Compensating transaction

Permette di fare rollback dei singoli step del processo

Semantic lock

Permette di assicurare che non ci siano transizioni impreviste usando una macchina a stati

Un componente fondamentale

(o ZeroMQ, Kafka, Amazon MQ o SQS, Google Cloud Pub/Sub, ActiveMQ...)

Due versioni possibili

Choreography

• Ogni microservizio può emettere un evento
• Ogni microservizio può fare subscribe a un evento

Orchestration

• Un componente dell'architettura, l'orchestrator, invia comandi agli altri
• Ogni microservizio riceve comandi dall'orchestrator e gli manda risposte

A confronto

Come lo facciamo noi (semplificato)

I nostri mal di testa

• Se l'orchestrator non riceve risposta?
• Se un oggetto è in uno stato inconsistente?

Bonus: Il tuo cloud provider supporta l'orchestration!

• AWS Step Functions
• Google Workflows
• Azure logic apps

Domande?