Random Employee Chats at Cloudflare

When the Coffee Machine Goes Remote

When Cloudflare’s offices closed in March 2020, the company lost more than just a workspace. Casual encounters—two engineers discussing a problem by the coffee machine, a designer catching up with a product manager in the hallway—disappeared overnight. Those interactions are the social fabric of an engineering organization, and Zoom meetings don’t naturally recreate them.

Engineer David Wragg proposed a simple fix: randomly pair employees for 30-minute video calls with no fixed agenda. The goal was to let people learn about other teams, get fresh perspectives on their own work, and meet colleagues they wouldn’t otherwise encounter. The first version worked—but barely. A shared spreadsheet tracked participants, and Wragg manually formed pairs and emailed results each week. The process functioned, but it depended on a single person doing repetitive work.

The natural solution was to automate it, and the natural platform was Cloudflare Workers. The result is a complete application that runs entirely on Cloudflare’s edge network with no origin server. It handles user registration, stores participant data, runs weekly pairing, and sends reminders—all on Workers with Workers KV for storage and Cron Triggers for scheduling.

Registration and the User Interface

The UI is deliberately minimal: it lists current participants and offers a register button for the next session. Clicking it calls an API that writes a key to Workers KV.

key: register:ID
value: {"name":"Sven Sauleau","picture":"picture.jpg","email":"[email protected]"}

Participant information lives in Workers KV and populates the list shown in the interface. Crucially, the data is deleted during each pairing cycle, so the list resets for the next round. That’s intentional: weekly sign-ups confirm that participants are actually available for that week’s chats, rather than assuming ongoing interest from a stale roster.

Pairing with Weighted Matching

Every Monday at 0800 UTC, a Workers Cron Trigger runs the pairing script. Wrangler configures the schedule using standard cron notation in wrangler.toml:

name = "randengchat-cron-pair"
type = "webpack"
account_id = "..."
webpack_config = "webpack.config.js"
…

kv_namespaces = [...]

[triggers]
crons = ["0 8 * * 2"]

The pairing logic begins by listing all users currently registered, using Workers KV’s list function to fetch keys with the register: prefix.

const list = await KV_NAMESPACE.list({ prefix: "register:" });

If the participant count is odd, one person is removed from consideration (David volunteered). The remaining people form a complete graph: each person is a node, and each edge is weighted by how many times the two connected people have already been paired.

async function countTimesPaired(key) {
  const v = await DB.get(key, "json");
  if (v !== null && v.count) {
    return v.count;
  }
  return 0;
}

With four participants (Tom, Edie, Ivie, and Ada), there are 6 possible pairs—4 choose 2—each carrying a weight based on past matches:

(Tom, Edie, 1)
(Tom, Ivie, 0)
(Tom, Ada, 1)
(Edie, Ivie, 2)
(Edie, Ada, 0)
(Ivie, Ada, 2)

The weight calculation is straightforward: it uses the number of prior pairings between two people, stored as a count in KV. This prevents the algorithm from repeatedly scheduling chats between the same two people. The system could account for other factors—office location, timezone, how recently they met—but the current implementation keeps it simple.

async function createWeightedPairs() {
  const pairs = [];
  for (let i = 0; i < keys.length - 1; i++) {
    for (let j = i + 1; j < keys.length; j++) {
      const weight = (await countTimesPaired(...)) * -1;
      pairs.push([i, j, weight]);
    }
  }
  return pairs;
}

The core of the application runs a weighted matching algorithm: the Blossom algorithm. It finds a maximum matching on the graph—a set of edges where every node appears exactly once—while minimizing the total path weights. This produces the optimal set of pairs, favoring combinations that have met least often.

In the example graph, the algorithm selects (Tom, Ivie) and (Edie, Ada), both pairs that have never met before. The chosen pairs are recorded back to Workers KV with an incremented match count, refining the weights for future sessions:

key: paired:ID
value: {"emails":["[email protected]","[email protected]", "count": 1]}

Each matched pair receives a notification. Once pairing completes, all register: keys are removed from KV, leaving a clean slate for the next registration cycle.

Weekly Reminders

The other scheduled job is a reminder that runs every Thursday at 1300 UTC, also configured via Cron Triggers:

[triggers]
crons = ["0 13 * * 5"]

This script is far simpler than the pairing logic. It sends a single message to a dedicated channel on the company messaging platform, notifying everyone to sign up for the following week’s sessions.

The full implementation—UI, API, pairing logic, and reminders—is available in the random-employee-chat repository on GitHub. It demonstrates that Workers, Workers KV, and Cron Triggers can support a real, multi-component application running end-to-end without a backend server—a useful pattern for any distributed team looking to rebuild its own hallway conversations.