Skip to content

Event Driven Architecture #670

Draft
tkallady wants to merge 6 commits into
devfrom
669-event-driven-architecture
Draft

Event Driven Architecture #670
tkallady wants to merge 6 commits into
devfrom
669-event-driven-architecture

Conversation

@tkallady

@tkallady tkallady commented Dec 2, 2025

Copy link
Copy Markdown
Contributor

Resolves #669

Adds foundation for event based actions, and implements an event based approach for answer recalculation. This can easily be extended to audit logs, notifications, sending email, etc.

yarn dev has been updated to also spin up event bus and worker.

The basic flow is:

  • a database update (e.g. update survey answers) occurs in an atomic transaction with creating an event and putting it in the 'outbox' table. A helper function (actionWithEvents) has been added for this purpose.
  • a worker process pushes events from 'outbox' to event bus.
  • the worker process receives multiple event consumers (e.g. RecalcConsumer) and applies them to every event. Each consumer is an extension of BaseConsumer and only needs to implement processEvent method (what to do with any given event).

For testing, minor changes are needed to ensure events are handled before proceeding with tests. I have created a helper function processEvents for this.

Currently, the event bus is implemented with redis, but it could easily be replaced with any other event bus. I've held off on building too much on redis in case we decide to use a different approach.

To do:

  • Test end to end including event bus
  • Handling of failed event consumer actions
  • Replaying of events
  • Add event bus and worker to helm

@ignatiusm

Copy link
Copy Markdown
Contributor

@tkallady looking forward to looking at the code, but first - I'm curious as to why you chose answer recalculation for this example event-based PR? I see the value of this approach for tasks where some asynchronicity is acceptable (e.g. emails; notifications; PDF creation). But for answer-recalcutation, in my mind, data integrity is critical and some eventual consistency is not acceptable. Presumably a changed guardian answer needs to be immediately reflected in the guardians - we don't want these to be out of sync. I'd argue that answer-recalculation is better suited to an atomic transaction approach than an event-driven approach. Ditto with audit log entries. Surely these are not demanding calculations for the DB and can be processed almost instantly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants