Building a microservice with event sourcing (I’ll use temporal to orchestrate different Workflow across different microservices and handle events).
I have a design question. My service receives commands and stores events on the database, lets say DynamoDB but it could be PostgreSQL or whatever… My question is about building the query models (views). I think it would be better to let temporal receive a response from the API (when sending commands) with the events that just happened in the system and then, with Temporal, change my query models to reflect the app’s current state. As I see it, this would be better than letting the microservice trigger other (Temporal) workflows for this since the API call might fail and I don’t have the retry logic handling implemented.
Temporal eliminates the need for explicitly implementing event sourcing and CQRS. When designing a Temporal application, convert external events to signals and queries to workflow queries. This greatly simplifies your application logic as you as a developer can focus only on your business logic while Temporal takes care of all the low level details.
Hi, @maxim I’ve thought about your answer and I buy it. Temporal replaces the need to implement CQRS and leaves all the complexity to the framework while I can focus on the domain logic.
But something is yet not clear to me. Let’s say I’m building an application to manage loans, I’m thinking about my temporal workflow as the Loan entity itself with signals to change the state, and so on… How does this scale with the billing for the temporal cloud solution… A Loan is usually not changed so much during its lifetime, you pay it every period_due_date (usually at the end of the month) and if you make an extra pay then the cashflows get updated; even if that’s the usual use cases then I’d pay for every single day the loans remains open? O just when the workflow gets triggered somehow (creation, signal, cron jobs)
Temporal cloud as of 09/22 charges for actions and storage. So workflow that waits on a timer and executes an activity each billing period will use 2 actions per billing period. An open workflow that is not executing any action is still charged for storage. Usually, workflows do not store a lot of data, so the storage charge shouldn’t be significant.