CQRS/Commanded and counting credits/usage

Caveat: I’m a major beginner in EventSourcing and CQRS.

What about something like the following?

1. Manage an Event Stream (aggregate) per User per Refresh Period (month, year, all time).
   • eg generation-account-bob-202402
   • This tracks not just the count, but the lifecycle of each generation request.
     • pending, completed, failed to complete, rejected.
   • Also can have event that indicates the number of allowed credits.
2. Use a SubmitGenerationCommand that includes
   • request identifier
   • request payload/details about the generation TBD
3. Handling the SubmitGenerationCommand can emit Events
   • GenerationSubmittedEvent – with request identifier
   • GenerationRequestRejectedEvent – with details such as:
     • max pending requests limit reached
     • max credits reached.
4. An Event Handler or Process Manager can watch for GenerationSubmittedEvent and then issue commands or execute API requests?
   • Then somehow events get back into the “generation-accounts” stream that would indicate success or failure?
5. And more Event Handlers would watch for Success/Failure events to then send message to update the “conversation”?

Basically, requests go into a “rate limiter” aggregate for that user-period. The Events of Submitted/Completed/Failed/Rejected requests allow the single aggregate to track the used credits count, pending credits such that used credits + pending <= allowed credits ? and can reject requests over the limit?

And follow-on Event Handlers will eventual consistently process (succeed or fail) the submitted requests?

The above uses patterns:

• Closing the Books – like accounting, so we can reset the user’s credit each period
• Many small streams, instead of big streams – A small stream of data for each user-time-period instead of a single stream for the user of all time.
• Write Ahead Pattern – we are writing the “request submitted” event to hold the pending place, then a Completion/Failed event to confirm the credit usage

We avoid:

• Reservation Pattern (book keeping) – because if the credit is reserved/booked, that reservation has an expiration because that ticket may never have been used/completed… And even then, the generation processor that receives the ticket and executes for a GenerationCompleted response MAY race condition with the ExpirationEvent.

[edit]: Here’s a suggested video that also talks about how to do different kinds of “business transactions” that spans multiple streams: