While building a file conversion and sharing app, I needed a way to show users the status of their file processing.
My initial thought was WebSockets.
Realtime updates sounded like the obvious choice.
But after thinking about the actual requirement, I realized users didn’t need instant push notifications — they only needed occasional feedback about whether conversion had finished.
So I went with polling every 2 seconds.
The flow became:
Upload → Job queued (BullMQ) → Worker processes file → Frontend polls status → Result ready
Why polling worked better here:
- Simpler architecture
- No persistent connections to manage
- No communication layer between workers and socket server
- Easier to debug and reason about
Tradeoff:
- More HTTP requests
- Users continue polling until processing completes
- Not suitable for low-latency or collaborative experiences
If the requirements change to things like chat, live collaboration, or instant notifications, I’d revisit WebSockets.
This was a good reminder that architecture decisions depend more on requirements than technology preferences.
SOCIAL SHARE CARD GENERATOR