I have the following servers running on my cloud, where each worker performs various long running tasks and may update my PostgreSQL database:
- Main application server
- Service that collects changes and updates my search database
- Worker
- Worker
- Worker
When my main server
, or either of my workers
updates my database, my ORM middleware emits a Cloud Pub/Sub event that the data has changed. This allows my search service
to then process the changes and update my search cluster in bulk batches.
The part I'm struggling with is simply where I should fetch the extra data required to process the events, while maintaining scalability and clean architecture.
For example:
I have accommodation properties that have their availability
synced externally. Each day
gets updated in my database and must reflect in the search index. The problem is that I also need the property's pricing model, and various other meta data to be updated in my search.
Should I:
A) Emit an event that a day
's availability has changed and in the Search Service
, fetch the property and it's pricing from the database
B) Fetch the property and it's pricing from the database in the ORM middleware, and THEN emit the event, allow the Search Service
to simply consume and update the search database
How generic should my PubSub events be, and how much data should be prepared before vs after the event has emitted?
question from:
https://stackoverflow.com/questions/65937879/should-i-emit-microservice-events-with-all-the-data-required-on-the-receiving-en 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…