A non-technical explanation for your Mom
Imagine you ordered some food online. You want to check the delivery status. You have 3 strategies to do that.
1. Be annoying – Short Polling
You can keep asking the same question over and over again. Food Delivery replies with the latest status every single time. However, why are you even doing that?
- Pros: ¯\_(ツ)_/¯
- Cons: You get tired. Food Delivery gets tired. You won’t be able to change anything. Just be patient.
- Use Cases: I can’t think of any other than a quick prototype. Don’t be that kind of person in your real life (aka. production environment).
2. Be normal – Long Polling
You ask Food Delivery to inform you when they are ready and they do.
- Pros: Effective. Async.
- Cons: Food Delivery needs extra efforts to track all their order status and push notifications to their customers.
- Use Cases: very common
3. You just can’t stop eating – Streaming
Food Delivery constantly delivers food to you. You just take it non-stop until you terminate the agreement.
- Pros: Super effective. You can eat lots of food within a short period.
- Cons: I wish you have a healthy stomach. I wish you have a plan to archive or destroy old food.
- User Cases: video/event streaming, messaging, etc
In short, what does that mean for engineers? For most use cases, you should avoid short polling, and stay with long polling (AWS SQS) for event-driven architecture, streaming (AWS Kinesis) for streaming data in real-time.
