The choice of architecture for a web service has a
significant contribution to this effect. We review the choices between
Event-Driven and the Big Data architectural styles.
Event Driven architecture consists of event producers and
consumers. Event producers are those that generate a stream of events and event
consumers are ones that listen for events
The scale out can be adjusted to suit the demands of the
workload and the events can be responded to in real time. Producers and
consumers are isolated from one another. In some extreme cases such as IoT, the
events must be ingested at very high volumes. There is scope for a high degree
of parallelism since the consumers are run independently and in parallel, but
they are tightly coupled to the events. Network latency for message exchanges
between producers and consumers is kept to a minimum. Consumers can be added as
necessary without impacting existing ones.
Some of the benefits of this architecture include the
following: 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.
Some of the challenges faced with this architecture
include the following: 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.
Some of the best practices demonstrated by this code.
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.
Some of the examples with this architectural style
include edge computing including IoT traffic. It works great for automations
that rely heavily on asynchronous backend processing and it is useful to
maintain order, retries and dead letter queues
No comments:
Post a Comment