Managing Global Job State

In this lesson, you will learn how to maintain a consistent view of background job statuses across multiple distributed worker processes.

When your Node.js application scales horizontally, you often have dozens of worker processes pulling tasks from a queue simultaneously. A common challenge arises when you need to know the global state of a job—for instance, checking if a specific task is "pending," "processing," or "completed" across the entire cluster. Because each worker process operates in its own memory space, local variables are useless for this purpose.

To manage global state, we must offload the status tracking to a shared, external source of truth, typically a high-performance database like Redis. Instead of relying on local state, every worker is responsible for updating the central registry every time a job transitions through its lifecycle.

Example: Tracking Job Status in Redis

Whenever a worker picks up a job, it should atomically update the job status in a shared store. This allows other parts of your system—such as an API dashboard or a monitoring tool—to query the exact progress of any job regardless of which worker is currently executing it.

const redis = require('redis');
const client = redis.createClient();

async function updateJobStatus(jobId, status) {
  // Use a hash map in Redis to track job metadata globally
  await client.hSet(`job:${jobId}`, 'status', status);
  await client.hSet(`job:${jobId}`, 'updatedAt', Date.now().toString());
}

// Inside a worker's processing logic:
async function processTask(job) {
  await updateJobStatus(job.id, 'processing');
  
  try {
    await performHeavyWork(job);
    await updateJobStatus(job.id, 'completed');
  } catch (err) {
    await updateJobStatus(job.id, 'failed');
  }
}

By externalizing this state, you decouple the execution logic from the visibility logic. It ensures that if a worker process crashes mid-task, your global state reflects that the job remains in an inconsistent state, allowing you to build recovery mechanisms that query the database to identify stalled jobs. This central coordination is the bridge that allows independent, ephemeral workers to act as a cohesive, reliable system.

Key Takeaway: Never rely on local memory to track job status in a distributed system; use an external, shared database as the single source of truth to ensure visibility and consistency across all worker processes.