Skip to content

SYSTEM Cited by 1 source

Unified Grid (Slack)

Unified Grid is the 2023–2024 re-architecture of Slack's client and backend that replaces the workspace-centric navigation model — where an Enterprise Grid user had to switch workspaces to see data on a different workspace — with an org-wide view of all channels and DMs the user can access across the Grid. It is the foundational layer beneath Slack's IA4 client redesign (the Activity / DMs / Later tabs). Rolled out Summer 2023 internally, Fall 2023 to customers, completed March 2024.

Why it was needed

Slack launched in 2013 with "almost all data is particular to a single workspace" as a core architectural assumption. Session tokens contained a workspace ID and the backend used the workspace ID to route queries to that workspace's database shard and perform access control. Enterprise Grid (2017) added a parent-to-workspaces "org" container with org-level shards for cross-workspace data — but users still navigated per-workspace.

By the late 2010s, a significant portion of Enterprise Grid users belonged to multiple workspaces on the same Grid, and compensating patches (Threads view, Unreads view, cross-workspace channels) kept adding org-wide surfaces on top of the workspace-centric substrate. Slack decided the founding assumption had to be revised rather than further patched (Source: sources/2024-08-26-slack-unified-grid-how-we-re-architected-slack-for-our-largest-customers).

Architectural preconditions

Two prior infra projects made the re-architecture feasible:

  1. Vitess migration re-sharded key tables along axes other than workspace or org ID — notably, the messages table is sharded by channel ID. This meant queries for messages in a channel no longer needed a workspace ID to find the right shard. See systems/vitess, concepts/horizontal-sharding.
  2. RTM stack rework removed the fan-out of org-wide data to every workspace on the Grid — "some of our largest customers have thousands of workspaces!" See systems/slack-rtm.

Without these two, Unified Grid would have needed to ship them concurrently, multiplying the blast radius. Lesson (canonicalised on the source page): the architectural re-axis is cheaper to do when the data layer has already been decoupled from the old axis.

The three API-fix strategies

"Unified Grid potentially impacted every API and permission check invoked by the Slack client" — thousands of APIs. The core-team playbook (Source: sources/2024-08-26-slack-unified-grid-how-we-re-architected-slack-for-our-largest-customers):

  1. Drop workspace routing entirely if the underlying table had already been re-sharded by Vitess (e.g. messages by channel ID). "We could efficiently fetch messages for a channel without significant changes."
  2. Prompt the user to pick a workspace if the API genuinely acts on a workspace (e.g. channel creation — the client can no longer infer the workspace from the session).
  3. Iterate over the user's workspaces and try each shard as a last-resort fallback. Performant for typical users (most are in "only a handful of workspaces") but pathological for the admin long tail. Bounded by capping "relevant" workspaces at 50 per user, with manual configuration (concepts/bounded-fan-out-relevance-cap).

Build substrate — not just the client

Beyond client code, Unified Grid required a platform that made the migration tractable:

  • New boot API returns data for all workspaces and channels the user belongs to across the Grid; clients store this at the org level rather than per-workspace.
  • API-framework Unified-Grid-compatibility mark — Slack's homegrown API framework was extended so an API could be explicitly tagged compatible with the new client. Default is "not yet compatible"; APIs graduate through two-pass migration.
  • Parallel integration test suite running thousands of existing integration tests under org context instead of workspace context (patterns/parallel-integration-test-suite-for-context-switch). Hundreds of initially-broken tests became the actionable list to fix per API.
  • Convenience helpers for fetching channels and performing permission checks across all of a user's workspaces on the Grid — e.g. checking whether a user can act as a workspace admin within a cross-workspace channel now checks whether the user is an admin in any of the workspaces the channel is shared with, or an admin at the org level.
  • Client-side data-model migration — some clients added an org-level store while continuing to save some data in workspace-scoped repositories; others moved everything to an org-wide store. "These data migrations could be completed and shipped in parallel with the overall Unified Grid project, which allowed us to de-risk the project itself."

Rollout: "prototype the path"

Slack's rollout methodology — canonicalised on the wiki as patterns/prototype-the-path — was the discipline: build a barely-working prototype, dogfood internally, let painful edge cases surface via real usage, fix them one by one, expand the user base in concentric rings:

  • Internal prototype — a Slack client that could boot in Unified Grid mode.
  • Core team dogfood — day-to-day usage by the engineering team.
  • Engineering org rollout — opt-in peers, gather feedback.
  • Exec opt-in — then-CEO Stewart Butterfield's "This is obviously better" was the signal the investment was worth the effort.
  • Summer 2023 — "much of the company was using it."
  • Fall 2023 — customer rollout begins.
  • March 2024 — customer rollout complete.

Unified Grid became a foundational dependency for IA4 — the redesigned Slack client's Activity / DMs / Later tabs are org-wide-by-design and could not be built on top of a workspace-scoped data model. Rather than ship IA4 and Unified Grid as two separate large changes, Slack coupled them, making Unified Grid "a top company priority" as a foundational component of IA4.

Seen in

Last updated · 470 distilled / 1,213 read