Het Probleem: Gedistribueerde Transacties in Hotelreserveringen

Laten we ons hotelreserveringssysteem opsplitsen in de belangrijkste onderdelen:

  • Reserveringsservice: Behandelt kamerbeschikbaarheid en boekingen
  • Betalingsservice: Verwerkt betalingen
  • Notificatieservice: Stuurt bevestigingsmails
  • Loyaliteitsservice: Werkt klantpunten bij

Stel je nu een scenario voor waarin een klant een kamer boekt. We moeten:

  1. De beschikbaarheid van de kamer controleren en reserveren
  2. De betaling verwerken
  3. Een bevestigingsmail sturen
  4. De loyaliteitspunten van de klant bijwerken

Klinkt simpel, toch? Niet zo snel. Wat gebeurt er als de betaling mislukt nadat we de kamer hebben gereserveerd? Of als de notificatieservice niet werkt? Welkom in de wereld van gedistribueerde transacties, waar de wet van Murphy altijd van toepassing is.

Maak Kennis met Sagas: De Onbezongen Helden van Gedistribueerde Transacties

Een Saga is een reeks lokale transacties waarbij elke transactie gegevens binnen een enkele service bijwerkt. Als een stap mislukt, voert de Saga compenserende transacties uit om de wijzigingen van de voorgaande stappen ongedaan te maken.

Zo zou onze hotelreservering Saga eruit kunnen zien:


def boek_hotelkamer(klant_id, kamer_id, betalingsinformatie):
    try:
        # Stap 1: Reserveer de kamer
        reservering_id = reserveringsservice.reserveer_kamer(kamer_id)
        
        # Stap 2: Verwerk betaling
        betaling_id = betalingsservice.verwerk_betaling(betalingsinformatie)
        
        # Stap 3: Stuur bevestiging
        notificatieservice.stuur_bevestiging(klant_id, reservering_id)
        
        # Stap 4: Werk loyaliteitspunten bij
        loyaliteitsservice.werk_punten_bij(klant_id, bereken_punten(kamer_id))
        
        return "Boeking succesvol!"
    except Exception as e:
        # Als een stap mislukt, voer compenserende acties uit
        compenseer_boeking(reservering_id, betaling_id, klant_id)
        raise e

def compenseer_boeking(reservering_id, betaling_id, klant_id):
    if reservering_id:
        reserveringsservice.annuleer_reservering(reservering_id)
    if betaling_id:
        betalingsservice.terugbetaling(betaling_id)
    notificatieservice.stuur_annulering(klant_id)
    # Geen compensatie nodig voor loyaliteitspunten omdat ze nog niet zijn toegevoegd

Idempotentie Implementeren: Omdat Eén Keer Niet Altijd Genoeg Is

In gedistribueerde systemen kunnen netwerkproblemen dubbele verzoeken veroorzaken. Om dit aan te pakken, moeten we onze operaties idempotent maken. Hier komen idempotentie sleutels in beeld:


def reserveer_kamer(kamer_id, idempotentie_sleutel):
    if reservering_bestaat(idempotentie_sleutel):
        return verkrijg_bestaande_reservering(idempotentie_sleutel)
    
    # Voer de daadwerkelijke reserveringslogica uit
    reservering = maak_reservering(kamer_id)
    sla_reservering_op(idempotentie_sleutel, reservering)
    return reservering

Door een idempotentie sleutel te gebruiken (meestal een UUID gegenereerd door de klant), zorgen we ervoor dat zelfs als hetzelfde verzoek meerdere keren wordt verzonden, we slechts één reservering maken.

Asynchrone Rollbacks: Omdat Tijd Op Geen Enkele Transactie Wacht

Soms kunnen compenserende acties niet onmiddellijk worden uitgevoerd. Bijvoorbeeld, als de betalingsservice tijdelijk niet beschikbaar is, kunnen we niet meteen een terugbetaling uitvoeren. Hier komen asynchrone rollbacks in beeld:


def compenseer_boeking_async(reservering_id, betaling_id, klant_id):
    compensatie_taken = [
        {'service': 'reservering', 'actie': 'annuleer', 'id': reservering_id},
        {'service': 'betaling', 'actie': 'terugbetaling', 'id': betaling_id},
        {'service': 'notificatie', 'actie': 'stuur_annulering', 'id': klant_id}
    ]
    
    for taak in compensatie_taken:
        compensatie_queue.plaats_in_queue(taak)

# In een apart werkproces
def verwerk_compensatie_queue():
    while True:
        taak = compensatie_queue.haal_uit_queue()
        try:
            voer_compensatie_uit(taak)
        except Exception:
            # Als compensatie mislukt, opnieuw in de queue plaatsen met exponentiële backoff
            compensatie_queue.plaats_opnieuw_in_queue(taak, vertraging=bereken_backoff(taak))

Deze aanpak stelt ons in staat om compensaties betrouwbaar af te handelen, zelfs wanneer services tijdelijk niet beschikbaar zijn.

De Valkuilen: Wat Kan Er Fout Gaan?

Hoewel Sagas krachtig zijn, zijn ze niet zonder uitdagingen:

  • Complexiteit: Het implementeren van compenserende acties voor elke stap kan lastig zijn.
  • Eventuele Consistentie: Er is een periode waarin het systeem in een inconsistente staat verkeert.
  • Gebrek aan Isolatie: Andere transacties kunnen tussentijdse staten zien.

Om deze problemen te verminderen:

  • Gebruik een Saga-orkestrator om de workflow en compensaties te beheren.
  • Implementeer robuuste foutafhandeling en logging.
  • Overweeg pessimistische vergrendeling voor kritieke bronnen.

De Beloning: Waarom Al Deze Moeite?

Je denkt misschien: "Dit lijkt veel werk. Waarom niet gewoon 2PC gebruiken?" Hier is waarom:

  • Schaalbaarheid: Sagas vereisen geen langdurige vergrendelingen, wat betere schaalbaarheid mogelijk maakt.
  • Flexibiliteit: Services kunnen onafhankelijk worden bijgewerkt zonder de hele transactie te breken.
  • Veerkracht: Het systeem kan blijven functioneren, zelfs als sommige services tijdelijk niet beschikbaar zijn.
  • Prestaties: Geen gedistribueerde vergrendelingen betekent snellere algehele transactieverwerking.

Samenvatting: De Belangrijkste Inzichten

Het implementeren van gedistribueerde transacties zonder 2PC met behulp van compenserende workflows en Sagas biedt een robuuste en schaalbare oplossing voor complexe systemen zoals hotelreserveringsplatforms. Door gebruik te maken van idempotentie sleutels en asynchrone rollbacks, kunnen we veerkrachtige systemen bouwen die storingen gracieus afhandelen en gegevensconsistentie over microservices waarborgen.

Onthoud, het doel is niet om storingen te vermijden (ze zijn onvermijdelijk in gedistribueerde systemen), maar om ze gracieus af te handelen. Met Sagas boeken we niet alleen hotelkamers; we betreden een wereld van betrouwbaardere en schaalbaardere gedistribueerde transacties.

"In gedistribueerde systemen zijn storingen niet alleen mogelijk, ze zijn onvermijdelijk. Ontwerp voor falen, en je bouwt voor succes."

Ga nu op pad en moge je transacties altijd in je voordeel zijn!

Verder Lezen

Veel programmeerplezier, en moge je gedistribueerde transacties altijd soepel en gecompenseerd zijn!