Comparing Event Based Architecture over Polling and Message Queue Based Systems
Comparing Eventing Service with Message Queue
To track data mutations, the Message Queue implementation adds a new layer. This new layer addition introduces dual-write problems. With multiple functional entities such as application layers, message queues and data platform entities, the debugging complexity increases. The overall data governance becomes a bit tricky as developers need to take into account the fault-handling, debugging and other management configurations. This in turn increases your total cost of ownership.
Eventing Service is native to Couchbase Server and does not need a new layer to record or propagate data changes. With no-dual writes, the write-failure condition is eliminated. Centralized data governance, layer consolidation, option to debug and reduced TCO aspects play an active role in increasing the overall user experience with the Couchbase Data Platform.
Polling
In the Polling implementation, application servers perform a write operation. Another application polls the data platform in order to track data changes.
Comparing Eventing Service with Polling
When large volumes of frequently changing data are encountered, the batch system in polling becomes ineffective. Factors such as CPU utilization, non-reactive tracking of data mutations, code duplication issues, contribute in increasing the system complexity. With these increased complexities, you cannot scale using the polling implementation.
The Eventing Service, on the other hand, can manage data changes within the cluster and also propagate these data changes to an end-point. Implemented as a state-less compute operation, the Eventing Service, utilizes latest trends in compute (multi-core CPU) and can scale easily.