A simple example of an event based architecture (in daily life) would be a postman sorting letters based on address. The “event” here is the arrival of new letters to sort.
If no letters arrive, the sorter will be idle, waiting for the letters to arrive. On the other hand if too many letters arrive at the same time, the sorter will stack those letters on his/her table and sort them based on their own speed.
The key takeaway here is the fact that the arrival of letters and sorting them is decoupled. The only bottleneck here is the size of the table on which the sorter can stack letters. The requirement is that all the letters should have an address.
The multiple producers of these letters (humans) can keep sending letters and be guaranteed the deliver of the letter (albeit not instantaneously). The consumers (sorter(s)) subscribe to the stream of letters and can sort/process them at their own speed.
This is impotant in distributed systems to do time intensive jobs that take a long time but don’t require instant results.
This allows your application to scale and be responsive independently of the time taken by these intensive jobs to complete.
A good example would be uploading video to youtube. You upload the video to youtube and youtube tells you that it will notify you when the video processing is complete.
In this scenario, your user facing application:
1) Accepts the uploaded video
2) Stores it in a location
3) Produces an event for consumers with details of video location
The consumer (a different server) would be listening for these events and do the video processing. After processing is complete, it would send a notification to the user.
Note: I don’t work with google. This is just an example of how I think it might work at a very basic level.
