Original post can be found on the Cloud Native blog.

One of the models to consider when moving into a cloud native architecture landscape is applying domain driven design. The general idea of domain driven design is to ensure technical functionality / services should match the domains of your business. This holds that functionality and services for (as an example) logistical warehouse services will be placed in a dedicated technical domain while services related to billing might reside in a dedicated domain for billing services and functionality.

Following an evolutionary model to move from a monolith-based application design into a cloud native service-based design will change the model of communication between the different business functionalities.

Where the model of communication between the different business functionalities is relative direct and relatively simple in the monolith-based design, it will radically change when moving to a cloud native service-based design. In a cloud native service-based design communication, connections, will be loosely coupled and will take both a synchronous as well as an asynchronous approach.

As part of the new communication model between the different services / functionality communication will be driven by event-based communication in the majority of the cloud native service-based designs.

Event driven architecture patterns

One of the prime issues with event-based architectures and talking about event-based architectures is that it is used as an umbrella term and multiple design patterns apply for this term. In addition to this, a level of debate comes to the table when trying to define what an “event” actually is.

Some people claim an event can be defined as; “a tangible change of state”. Even though a tangible change of state can define an event, however, it rules out a lot of other situations which could be eligible for the term “event”.

As per OxfordLanguages and event is; “a thing that happens or takes place, especially one of importance”. Even though this is less tangible it is more applicable. Reason for it being more applicable when talking about event driven architecture patterns is that not all events in a system are by definition a change of state. Some events are relative volatile however are still of importance. An example of this could be a reboot of a service, an event that is important, even though it is not a tangible change of state in the sense of an update of a database record.

The second big debate that can be had is, what is the event driven architecture pattern applied when talking about “event driven”. In a now almost famous post from Martin Fowler from ThoughtsWorks he discusses this specific subject and comes down to the following patterns that can be referenced when talking about event driven;

  • Event Notification
  • Event-Carried State Transfer
  • Event-Sourcing
  • CQRS

From the above patterns the “event notification” and the “event-Carried State Transfer” are the most commonly used in cloud native architectures. In this article we will discuss “Event Notification” in the context of domain driven eventing in Cloud Native landscapes on Oracle Cloud.

Inter-domain and intra-domain event streams

The concept of Event Notification is that whenever an event occurs we inform the rest of the world about it by broadcasting the fact that the event happened. The event notification message normally only holds what has changed and where the details can be located.

This model follows the idea of producers and consumers, the producer is the system where the event occurs and who will publish the event notification to the wider world. consumers are the systems who subscribe “listen” to all the published events.

A common way of implementing this on a technical level is using the OCI Streaming Service to publish message on a stream. The Oracle Cloud Infrastructure Streaming service provides a fully managed, scalable, and durable solution for ingesting and consuming high-volume data streams in real-time. Streaming is compatible with most Kafka APIs, allowing you to use applications written for Kafka to send messages to and receive messages from the Streaming service without having to rewrite your code.

In a domain driven design one of the things that will require a level of thinking is the positioning of your streams. As a rule of thumb, it is advisable to make a distinct difference between inter-domain streams and intra-domain streams as shown in the diagram below.

The use of intra-domain streams is to allow the publishing of events that are intended only to be consumed by subscribers within the same domain as the producer. The diagram above shows a single intra-domain stream, in reality this could be split into multiple intra-domain streams where each stream will be dedicated for a specific event topic.

For events that are potentially of interest to services outside of the domain where they are being produced the model of enterprise wide events streams or inter-domain streams, can be used. This model allows a producer to publish a message to a stream which can be consumed by services both inside as well as outside of the domain where they are being published.

Event Notification API Callback

The principle of event notification is that the payload of the event notification will only carry information of the fact that an event did occur and where additional information can be retrieved. Retrieval of additional information is commonly done via a call to an API endpoint by the consumer.

As an example, a producer could send an event notification that a shipping address for a customer has changed. The consumer who subscribed to event notifications on shipping address updates will receive this and will do a callback to the service that holds the shipping addresses to get all the insights on the event.

A benefit of this model is that the service who holds the shipping addresses can relatively strictly control who can retrieve which detailed information while at the same time be relatively relaxed on producing the event notifications. As the event notification will not hold any specific details it will not contain personal or restricted data and the event message itself can be under less strict security rules from that point of view.

In the diagram above we see that a service in business domain A produces an event. Following the shipping address example this could hold a payload stating that there is an “update” on “shipping address” for customer “124” as well as a direct API location to get all the details of the newly updated record.

In this example a service in business domain B consumes this event notification and based upon the business logic in the service it requires the additional information. To acquire the additional information service B will reach out to the endpoint of the service in business domain A via the exposed service endpoint in the API Gateway.

The example shown above is a typical event notification flow that is currently being implemented regularly in cloud native deployments. When implementing the above a much more detailed design will be required, however the above shows a clear conceptual view of the event notification pattern and how to perceive this in a domain driven design landscape for cloud native application deployments.

Prevent and handle request storms

One of the tricky parts when designing an event notification model is the issue of request storms, how to handle request storms, prevent negative side effects and how to stay true to event notification when trying to prevent issues.

The request storm issue is the following; a service sends out an event notification message. A large group of consumers all receive the event notification at the same time and they all require additional information. All the consuming services do a request to the API of the producing service at the same time and by doing so they exhaust the service. A self-inflicted denial of service situation occurs as the producing service is unable to handle all the requests at the same time.

A number of possible solutions directions are available, all having an upside as well as a downside. 

  • Size the service; you can size the service bigger to ensure it can handle all the request in case of a request storm. The downside is that the sizing is potentially only needed in a small number of cases and a limited amount of time.
  • Scale the service; you can (auto-)scale the service, before sending out the event notification you could add more nodes to the service to handle the storm and scale back when the request storm has passed.
  • Cache the data; you could pre-cache the data of the event and add logic to your service that for the request in the request storm the requests are routed to a simple however fast and isolated sub-service. Downside is that you need to add extra functionality and complexity to the service logic.
  • Add more data to the event; A common approach is to add more detailed data to the event notification to enable the consumers to make a more informed judgment if they need to call the API for additional information. The downside is that the more you add to the event notification payload the further you drift away from the Event Notification pattern and you move more into the Event-Carried State Transfer pattern.

Not a single answer can be given on how to handle request storms in an event notification-based model, the guidance that can be given is that one needs to think of this at an early stage and needs to be aware of the possible problem to ensure they can relatively easy incorporate measures when needed.

In conclusion

Event based patterns play an important role in Cloud Native architectures, they especially play an important role when applying Domain Driven Design to your architecture. When designing a solution that will work with a form of Event Driven Architecture it is required to take a bit of a deeper thought on details to ensure a solid common model can be used across domains and to ensure you mitigate against a number of known problems that can occur if you do not take them into account in the beginning.

When deploying Event based patterns in Oracle Cloud a large number of pre-defined building blocks can be leveraged out of the box in the form of managed services to ease the implementation and provide a highly available and stable end-state. The OCI Streaming Service and the API Gateway service are services that come to mind directly, additional services are available and can be leveraged to enrich the end-state solution.