Skip to content

ADR_00004: Použití Inbox / Outbox patternu pro asynchronní komunikaci

Status: Proposed / Accepted
Date: 2025-12-28


Context

Systém je postaven na:

  • více core doménách,
  • event-driven architektuře,
  • asynchronní komunikaci mezi službami,
  • požadavku na spolehlivost a auditovatelnost komunikace.

Přímá komunikace mezi doménami není vždy spolehlivá:

  • hrozí ztráta zpráv,
  • nekonzistence dat,
  • problémy s retry,
  • závislost na dostupnosti cílové služby.

Je potřeba mechanismus, který:

  • zaručí doručení událostí,
  • oddělí transakční logiku od komunikace,
  • umožní bezpečné retry.

Decision

Každá core doména implementuje Inbox / Outbox pattern.


Outbox

  • Outbox je součástí databáze domény.
  • Ukládají se do něj:
    • doménové události,
    • integrační eventy.
  • Zápis do outboxu probíhá ve stejné transakci jako změna dat.

Worker:

  • čte z outboxu,
  • publikuje eventy do message brokeru,
  • označuje je jako zpracované.

Inbox

  • Inbox přijímá eventy z jiných domén.
  • Slouží jako:
    • ochrana proti duplicitám,
    • zajištění idempotence,
  • kontrola pořadí zpracování.

Worker:

  • čte eventy z inboxu,
  • spouští aplikační logiku,
  • ukládá výsledek do domény.

Consequences

Pozitiva

  • Garantované doručení zpráv
  • Odolnost vůči výpadkům
  • Idempotentní zpracování
  • Podpora event-driven architektury
  • Konzistentní stav systému

Negativa

  • Vyšší implementační složitost
  • Nutnost správy workerů
  • Nutnost monitoringu a DLQ

Rationale

Rozhodnutí Důvod
Outbox Zaručuje, že event odpovídá změně dat
Inbox Zabraňuje duplicitám a nekonzistenci
Asynchronní zpracování Vyšší odolnost a škálovatelnost
Worker Oddělení domény od integrace

Considered Alternatives

  • Nekonzistence/problémy řešené přes broker retry

    • V případě chyby při zpracování, retry na úrovni brokeru přes retry queue-topic
    • Výhody:
      • Nižší overhead v aplikaci
      • Není třeba inbox tabulka a její zpracování
    • Nevýhody:
      • Tvorba zbytečných zpráv
      • Rotace eventů
      • Nejasná forma zpracování
      • Idempotence musí řešit aplikace
  • Nekonzistence/problémy řešené přes aplikační retry

    • V případě chyby při zpracování, retry na úrovni aplikace
    • Výhody:
      • Není třeba inbox tabulka a její zpracování
    • Nevýhody:
      • Nutnost použití poly nebo jiného mechanismu
      • Z pohledu brokera je zpráva zpracovaná
      • Zatěžování procesu exportem eventů (sync místo async)
      • Idempotence musí řešit aplikace
  • Místo outboxu posílat zprávy rovnou

    • V případě chyby při zpracování, retry na úrovni aplikace
    • Výhody:
      • Není třeba outbox tabulka a její zpracování
    • Nevýhody:
      • Závislost na dostupnosti cílové služby během transakce
      • Retry mechanismus musí řešit aplikace