Building a Stateful, Session-Based Worker Tier on Heroku (Circa 2015)

In 2015, building real-time, compute-heavy web applications often meant navigating the limitations of ephemeral cloud environments. Heroku was the undisputed king of PaaS, but its router had a strict 30-second timeout. If you needed to process heavy, stateful datasets for an active user session, you couldn't do it on the web dyno. The solution? A custom, cloud-native worker tier that spun up dedicated processes per user session, retained data in memory, and communicated asynchronously. Here is a look at how to architect this system using Node.js, Socket.IO, Redis, and the Heroku Platform API. 1. The Architecture: A Session-Based Worker Model Unlike traditional background job queues (like Celery or Resque) where anonymous workers pick up stateless tasks, this architecture requires a 1:1 mapping between a user session and a worker process. When a user connects via a WebSocket, the system provisions a dedicated worker. This worker loads the user's specific dataset into memory and waits fo