Comparisons between web-queue-worker and event driven architecture.

Introduction:

This article is a comparison of two architectural styles in building services for the public cloud.

Description:

The two architectural styles correspond to:

1.       Event-Driven architecture style: Event producers that generate a stream of events and event consumers that listen for events

2.       A microservices architecture that consists of a collection of small, autonomous services. 

This is a comparison of the features and their relative price comparisons as low or high:

Feature/Subsystem	Event-Driven Architecture	Microservices
Organization	Events are produced in near real-time, so consumers can respond immediately to events as they occur.	Each Service is self-contained and implements a single business functionality encapsulating a domain model.
Management	Subscribers can be added as necessary without impacting existing ones.	Services can be added as necessary without impacting existing ones
Benefits	The publishers and subscribers are decoupled. There are no point-to-point integrations. It's easy to add new consumers to the system. Consumers can respond to events immediately as they arrive. They are highly scalable and distributed. There are subsystems that have independent views of the event stream.	This is a simple architecture that focuses on end-to-end addition of business capabilities. They are easy to deploy and manage. There is a clear separation of concerns. The front end is decoupled from the worker using asynchronous messaging. The front end and the worker can be scaled independently.
Challenges	Event loss is tolerated so if there needs to be guaranteed delivery, this poses a challenge. Some IoT traffic mandate a guaranteed delivery Events are processed in exactly the order they arrive. Each consumer type typically runs in multiple instances, for resiliency and scalability. This can pose a challenge if the processing logic is not idempotent or the events must be processed in order.	Care must be taken to ensure that  the front end and the worker do not become large, monolithic components that are difficult to maintain and update. It hides unnecessary dependencies when the front end and worker share data schemas or code modules.
Best practices	Events should be lean and mean and not bloated. Services should share only IDs and/or a timestamp. Large data transfer between services in this case is an antipattern. Loosely coupled event driven systems are best.	Expose a well-designed API to the client Autoscale to handle changes to load Cache semi-static data Use a CDN to host static content Use polyglot persistence when appropriate Partition data to improve scalability
Examples	The event driven architecture is suitable for edge computing including IoT traffic Works great for automations that rely heavily on asynchronous backend processing Useful to maintain order, retries and dead letter queues	The microservices are best suited for expanding the backend service portfolio such as for eCommerce Works great for transactional processing and deep separation of data access Useful to work with application gateway, load balancer and ingress.

Conclusion:

These are some comparisons between the two styles.