Tiffin's operations team wants a number on a big screen: "orders placed in each city in the last 5 minutes". The obvious way is a SQL query against the orders database, every 10 seconds, for every city. That works at first. Then the fraud team wants "customers who cancelled 3 orders in an hour". Marketing wants "restaurants whose orders suddenly dropped". Each new question is another heavy query, polling the busiest database in the company at dinner time.
There's another way to get those answers. Order events are already flowing through Kafka (Module 15). Instead of asking the database over and over, you can compute each answer as the events go past, keeping a small running total in memory. That's stream processing.
Asking again versus keeping a running total
Think of a cricket scoreboard. Nobody recounts every ball of the innings each time the score changes. The scorer keeps a running total and adds each ball as it happens. Stream processing works the same way.
Stream processing means computing results continuously from an unbounded flow of events, updating the answer as each event arrives instead of re-reading all the data.
The input never ends. There is no "last row". That one fact shapes everything else in this module: you can't wait to see everything before answering, so you need running state, and you need a way to decide when a result is ready (next lesson).