You ask – I answer
(if I can)
- Q: Why Microservice Architecture does not recommend implementing transactional behaviour over several Microservices?
A: Here are more than one reason for such recommendation: Microservice Architecture (MA) is intended for one Developer would be able to design, build and deploy one Microservice (Ms) with minimal dependencies on others, though this is not a “must have” rule. A transaction over a few Ms requires 1) additional contacts with Developers of other Ms, 2) learning their interaction interfaces, and 3) agreeing on their availability and robustness. Also, 4) here has to be an additional design and implementation of transaction fail-over and, where possible, compensation. All these slows down the Developer’s productivity and contradicts principle of maximum autonomy of the Ms. Nonetheless, the task of transactions is a natural business task and it stays with IT Development. If MA is considered unsuitable for this task, another technology or different Developers should be used for its realisation. – M.P.
- Q: How effective Event Polling in comparison to messaging for Microservices?
A: Messaging as a pattern and its early implementations in IBM MQ, Tibco, Java JMS, WebLogic, Red Hat and others were based on two fundamental pillars: 1) messaging infrastructure (MI) decouples senders from receivers, i.e. they did not need to know about each other – not-transactional behaviour, and 2) MI always pushed (durably, reliable or not) received messages to the receivers. That is, the sender was assured that the message is delivered though at unknown time. Event Polling can keep the message for a long time, like Kafka, but there is no assurance, not at all, that the message would be delivered ever – the receiver may not exist or be down and never pulls the message from the MI. Since the sending and receiving Ms may be under different ownership and management, there is no formal mechanism to provide check-up and notifications or enforcement for the receiving Ms to pull the message. An effectiveness of using Event Polling or Messaging depends on the goal – it may be a “fire and forget” or “hub and forward”. In the former case moth methods are equally effective, but in the latter case Messaging is much more effective than Event Polling. – M.P.