The latest articles on DEV Community by Uttkarsh singh (@uttkarsh123shiv). https://dev.to/uttkarsh123shiv https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3948650%2F6f9d1b43-623a-4895-9dba-c0d36c2fead9.png https://dev.to/uttkarsh123shiv en Uttkarsh singh Sun, 24 May 2026 07:06:59 +0000 https://dev.to/uttkarsh123shiv/1-why-i-chose-polling-over-websockets-for-file-processing--4242 https://dev.to/uttkarsh123shiv/1-why-i-chose-polling-over-websockets-for-file-processing--4242 <p>While building a file conversion and sharing app, I needed a way to show users the status of their file processing.</p> <p>My initial thought was WebSockets.</p> <p>Realtime updates sounded like the obvious choice.</p> <p>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.</p> <p>So I went with polling every 2 seconds.</p> <p>The flow became:</p> <p>Upload → Job queued (BullMQ) → Worker processes file → Frontend polls status → Result ready</p> <p>Why polling worked better here:</p> <ul> <li>Simpler architecture</li> <li>No persistent connections to manage</li> <li>No communication layer between workers and socket server</li> <li>Easier to debug and reason about</li> </ul> <p>Tradeoff:</p> <ul> <li>More HTTP requests</li> <li>Users continue polling until processing completes</li> <li>Not suitable for low-latency or collaborative experiences</li> </ul> <p>If the requirements change to things like chat, live collaboration, or instant notifications, I’d revisit WebSockets.</p> <p>This was a good reminder that architecture decisions depend more on requirements than technology preferences.</p> architecture backend systemdesign webdev