Message based concurrency is a share nothing approach: no business object is shared between the various collaborating systems. Note that ‘systems’ here covers both application/services and thread, and they are usually referred to as ‘agents‘, ‘actors‘ or ‘nodes‘, depending on the messaging strategy. I will refer to those as ‘agents’ for the rest of this entry.
Instead of sharing entities, agents send messages detailing part or whole current state of one or more entities. For example, whenever a new article is added to a basket by an agent, it will send the content of the basket to the agent dedicates to computing the total value of the basket, which in turn will communicate back the updated total.
This approach is also known as ‘Event driven’ architecture.
Note that this approach fits nicely with inversion of control, and often include facilities allowing any agent to receive notification for any entity it is interested in.
- Share nothing means no race condition (at the entity/data level)
- Message passing helps keeping coupling low
- It eases horizontal scalability (message can be in or cross process)
- Synchronization is hard, but less needed
- Provides eventual consistency (due to little to no synch)
- Harder do debug
Overall message based concurrency is a very good model. Learning curve is a bit steep, but resulting systems are stable and scalable. Unless hard consistency is a strong requirement, you should consider using message based concurrency before anything.
This is my personal favorite for quite some time now, and I am still waiting for a use case where it would not be the best approach.
The hard parts are:
– living in an eventually consistent world
– managing asynchronous operations
– identifying the adequate libraries