-
Notifications
You must be signed in to change notification settings - Fork 55
Push versus Pull integration
In our example we have a sales and accounting and sales needs to know the status of the either new or existing customer before making decisions, so it needs to know something about customers.
If accounting goes down, and sales' read model is pull based - then also sales can't make further business decisions.
Accounting sends AccountBalanceUpdated
- sales has event handler that writes to a "read model" which becomes its source of truth for business decisions.
If accounting goes down, the sales' read model stops getting updated.
When sales is "down" it's because its data is simply too stale from business' perspective - e.g. the business could state that 2 days old data is too old - it's still possible to use the data at this point, however.
Another aspect of the above systems is if we separate Accounting and Sales geographically and 'assume high latency' between them - with a push-based model where the different systems build their own local data models, queries could be made with low latency (to e.g. build GUI views) and operations that need cooperation between the two systems could be implemented with Sagas + Messages (still queue-based). The Sagas would still be based on the low-latency program constructs, but would degrade gracefully and allow business to degrade SLA in response.
Let's say Sales wanted to integrate the concept of GetInventoryVelocities
, a sales concept. In a pull based system the sales team would go over to their project manager and ask him to ask the accounting team to create that new service, implementing inventory velocities.
With this pull-based integration model, the decision of implementing the feature that the sales team needs, we're required to block on this other team, another bounded context - the bonded contexts are starting to leak together and we're getting accidental complexity.
Also, the accounting team would have to know what inventory velocities need to know or learn what inventory velocities are.
With a push based system the accounting team would send their events as normal and something like NEsper or a custom-coded event listener could be used in the Sales' bounded context, rather than leaking into Accounting.
It comes down to how different contexts are interacting.
- How to integrate with AMQP (Advanced Messaging Queueing Protocol) - http://www.rabbitmq.com/blog/2011/06/22/federation-plugin-preview-release/ - RabbitMQ Federation Plugin