Skip to content

Integration Messages

Events and CQRS via Kafka

Overview

PayCenter apps currently use patterns:

  • Integration events for async event processing via RMQ.
  • CQRS-style requests for mostly synchronous command/query interactions.

Otto will retain this practice sans RMQ. The project also has a need for:

  • "Suspenders" - Get the status of thing in an async manner
  • "Fixers" - Send a command (or event with intent, see note below), but in an async manner.

These requirements align with a request/response pattern, so we can leverage the event stream broker to facilitate asynchronous CQRS-style requests.

Today: CQRS - Command Query Separation

From Stackoverflow:

CQRS is "splitting a model object into two". You will have one model to write and one model to read, which are completely separate. You might store your data in the same database, but where you write to using your commands is separated from where you read from using your queries, they use different models (write and read).

All API requests fall within:

  • Requests
  • Commands
    • Handler usually defers to the domain.
  • Queries
    • Handler could return a domain entity.
    • Handler could directly call a stored-procedure.

MediatR handles the request dispatching. This practice will continue with Otto.

Today: Integration Events

Integration events inform other contexts and systems of activities of a bounded context.

Examples:

  • WSO2 adds a payment -> event -> Recon processes event.
  • PaymentRepo.Zelle sets status to failed -> event -> PaymentRepo.Limits updates limits

RMQ is currently the broker in both cases.

Integration Messages

file

Integration Events

A participating system1 communicates that something of note has occurred.

Publishers:

  • Source systems2
  • Otto
    • When flagging a rule condition
    • alternative to using a "fix" command

Consumers:

  • Otto
    • updates model
    • runs rules
  • Source systems2
    • Consume rule flag actions. Otto is indicating that something should be fixed.

Examples:

  1. CPR adds a payment
  2. CPR -> pc.qa.pmt.fct.cpr.PaymentAdded -> otto
  3. Otto updates the model

See also Event Flow

Integration Requests

Based on CQRS, but with a an event stream as the transport.

Integration command

Otto requests that something gets fixed, such as a stuck status.

Note

We may not need this. An alternative is to instead dispatch an integration event to signify that Otto has flagged something amiss for a payment. The source system would be the consumer.

Integration query

Otto requests the status of a core transaction

Example:

  1. Otto requests confirmation of a TrnAdd
    • Otto -> pc.qa.pmt.cmd.otto.GetTrnRq -> wso2
  2. Wso2 UC calls TrnAdd and publishes response
    • Wso2 -> pc.qa.pmt.cmd.otto.GetTrnRs -> otto
  3. Otto updates the model

References

JHA eDocs Data Modeling

From topic name guidelines under Classification -> cmd:

cmd Command topics represent operations that occur against the system. This is typically found as the request-response pattern, where you have a verb and a statement. Examples might include UpdateUser and UserUpdated.

  1. Payments Integrity participating systems

    • Otto
    • Source systems
      • Blue PaymentRepo
      • Blue WSO2
      • SettlementRecon
      • Reporting

    ↩

  2. Payments Integrity source systems

    • Blue PaymentRepo
    • Blue WSO2
    • SettlementRecon
    • Reporting

    ↩↩