> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# What is Event Streaming
> Defines event streaming, its roles and platforms like Apache Kafka, and real-time use cases such as taxi app flows, durable logs, ordering, replay, and stream processing
Hello and welcome — in this lesson we'll define what event streaming is, why it matters, and how it’s used in real systems.
At a high level, an event is a recorded fact about something that happened. In streaming platforms (for example, [Apache Kafka](https://kafka.apache.org/)) an event is usually an immutable, append-only record that captures “what happened” at a point in time. A typical event record includes a key, a value (the payload), and metadata such as a timestamp, schema version, and headers.
When you watch live video, you don’t receive a single packet — you receive a continuous sequence of packets. That continuous flow of events is called an event stream, or simply streaming. An event stream carries many individual events over time, and consumers process or react to each event as it arrives.
Event streaming is the continuous generation, transmission, storage, and processing of event data in (near) real time. This enables immediate analysis, transformation, and automated reactions to events as they occur — powering use cases like analytics, monitoring, notifications, and real-time business workflows.
An event typically contains: a timestamp, an immutable payload (the fact), an optional key for partitioning or routing, and metadata for schema and tracing. Streams let consumers process events in order (often ordered per partition/key in systems like [Apache Kafka](https://kafka.apache.org/)), replay historical events, and decouple producers from consumers.
## Example: Taxi-hailing app (event-driven flow)
To make this concrete, consider a taxi-hailing app. As a ride progresses, the app and related services emit a sequence of events. Different services (dispatch, driver app, billing, telemetry, analytics) consume or produce these events independently.
A compact sequence for a typical taxi booking:
1. Customer booking request (Event 1)
* The rider taps “Request ride”. The app emits an event with pickup, dropoff, and rider details.
2. Driver accepts booking (Event 2)
* A candidate broadcast is sent to nearby drivers. When a driver accepts, an acceptance event is emitted with driver id, vehicle details, and ETA. The rider app receives the update.
3. Driver arrives and ride starts (Event 3)
* The driver’s app emits an “arrived” event and then a “ride started” event. This triggers status updates and starts billing.
4. Telemetry / route events (Event 4)
* During the ride, the driver’s device sends frequent telemetry (GPS, speed, heading). These high-frequency events support routing, safety, and analytics.
5. Traffic and routing metadata (Event 5)
* Events from traffic services or routing engines capture delays or route changes used to adjust ETA, pricing, or notifications.
6. Trip end and payment settlement (Event 6)
* A trip-completed event triggers payment settlement, receipts, commission calculations, and analytics pipelines.
Each event is durable and ordered (often scoped by partition or key). Downstream services subscribe to the log and process events independently — e.g., billing listens only for completed trips, while analytics consumes telemetry streams.
Example JSON for a ride-started event:
```json theme={null}
{
"key": "ride-1234",
"timestamp": "2025-08-01T12:34:56Z",
"value": {
"eventType": "ride_started",
"rideId": "ride-1234",
"driverId": "driver-987",
"riderId": "rider-555",
"pickup": {"lat": 40.7128, "lon": -74.0060},
"startTime": "2025-08-01T12:34:50Z"
},
"headers": {
"schema-version": "v1"
}
}
```
## Who consumes events — quick mapping
| Event type | Typical consumers | Purpose |
| ----------------- | ----------------------------------------- | ------------------------------------ |
| Booking request | Dispatch, matching service, notifications | Start matching and notify drivers |
| Driver acceptance | Rider app, dispatch, logging | Confirm assignment and update UI |
| Telemetry | Routing, monitoring, analytics | Real-time routing and health metrics |
| Trip completed | Billing, receipts, analytics | Trigger payment and reporting |
## Reliable delivery: event streaming platforms
In real systems, events are passed reliably using an event streaming platform — a durable distributed log such as [Apache Kafka](https://kafka.apache.org/), or managed services (cloud providers’ streaming offerings). These platforms provide:
* Durable storage of events (the append-only log) for replay and recovery
* Message delivery and ordering guarantees (often per partition)
* High throughput and low latency for real-time processing
* Integration points for stream processing frameworks that transform, enrich, and aggregate events
Event streaming platforms serve three core roles: durable storage of events (the log), message delivery to consumers, and stream processing (real-time transformation, enrichment, or aggregation).
## Key takeaways
* An event is a recorded fact about something that happened — typically immutable and timestamped.
* An event stream is a continuous sequence of events that systems can consume and react to in real time.
* Event streaming decouples producers and consumers, supports replay, and enables real-time business logic via durable, distributed logs like [Apache Kafka](https://kafka.apache.org/).
## Links and references
* [Apache Kafka — official site](https://kafka.apache.org/)
* For conceptual reading: [Streaming vs. Messaging patterns](https://martinfowler.com/articles/streaming.html)
* Stream processing frameworks and platforms: explore Kafka Streams, Flink, and managed streaming services from cloud providers.