Events are actions or processes in response that happen in a software system. Examples of events might include a customer logging into a service, updating inventory, or a payment transaction completing. There are actions which are complex which arelike verification request, closing or open ticket or updating e-commerce datbase. For instance, On clicking “purchase”,credit card is processed to empty the shopping cart, automatially the inventory datbase is updated and confirmation mail to user is sent. Event streaming reflects how businesses actually work—thousands of small changes happening, all day, every day.

What is event streaming: Event-driven architecture?

One of the inherent challenges with microservices is the coupling that can occur between the services. In a conventional ask, don’t tell architecture, data is gathered on demand. Service A asks Services B, C, and D, “What’s your current state?” This assumes B, C, and D are always available to respond. However, if they moved or they’re offline, they can’t respond to Service A’s query.

To compensate, microservice architectures tend to include workarounds (such as retries) to deal with any ill effects caused by changes in deployment topology or network outages. This adds an extra layer of complexity and cost.

Event streaming attempts to solve this problem by inverting the communication process among services. An event-driven architecture utilizes a tell, don’t ask approach, in which Services B, C, and D publish continuous streams of data as events. Service A subscribes to these event streams—processing the facts, collating the results, and caching them locally. However, Service A only needs to act, or perform its function, when it is delivered a specific type of event.

Using event streams in this way can deliver a number of benefits, including:

1. Systems that more closely mimic real-world processes, because software teams have carefully considered the optimal flow.
2. Increased utilization of scale-to-zero functions (or serverless computing), because more services can remain idle until they’re needed.
3. Improved flexibility, because new requirements or features can be captured in loosely coupled microservices instead of rewriting the business logic of a large monolith.

What is event streaming: Streaming data?

Streaming data means a constant flow of data, each containing information about an event or change of state. Streaming data is processed in real-time as it’s delivered to a system, although the type of data or the nature of events typically will affect any resulting action. Notably, any given event flowing in from a data stream might not be immediately actionable.

Streaming data is unbounded, meaning it has no real beginning and no real end—each event is processed as it occurs and managed accordingly. Events can trigger specific application behaviors and feed real-time business dashboards, as well as make their way into other systems for later batch processing. This is in contrast to legacy approaches, where, by default, data is sent to a backend data warehouse or Hadoop cluster to be analyzed every day, week, month, or quarter.

The stock market is a common example. Every time a stock price changes, a new message is created containing, among other things, the time of day, the stock’s code, and its new trade price. Because an exchange might house thousands of individual stocks and handle millions of trades per day, the result (at least during trading hours) is a constant stream of data. How an organization analyzes or acts on that data—and how frequently it does either—depends on any number of factors specific to the organization’s business.