Skip to content

CONCEPT Cited by 1 source

Per-tenant workspace isolation

Definition

Per-tenant workspace isolation is the multi-tenancy shape where the tenant boundary is an opaque "workspace" inside a third-party SaaS that the platform provisions and operates programmatically. The vendor itself enforces the boundary — data, configuration, templates, identity, and (often) rate-limit budget are separated at the workspace grain. The platform's job is no longer implement the isolation primitives myself but provision the workspace + automate the operational gaps the vendor doesn't fill.

Canonical instance — Instacart Storefront Pro marketing

The 2026-05-14 source (sources/2026-05-14-instacart-scaling-personalized-marketing-for-multi-tenant-commerce-platforms) is the wiki's first canonical instance:

"We provision a dedicated workspace for each retailer within the third-party provider. A workspace is an isolated account with its own customer data, templates, and configuration. This per-retailer workspace model guarantees data isolation and brand integrity across the platform."

What the workspace boundary contains, per the source:

  • Customer data — each retailer's customer base lives only in that retailer's workspace; cross-retailer lookups are impossible at the API level.
  • Templates — branded email + push notification templates are uploaded into the retailer's workspace; another retailer's templates can't be referenced.
  • Configuration — workspace-level settings (sender identity, branding, integrations).
  • Rate-limit budget — vendor-side rate limits are applied per workspace (see concepts/per-tenant-rate-limit).
  • Failure-isolation domain — Instacart explicitly "isolate[s] failures at the workspace level so issues affecting one retailer do not cascade across the broader system." The workspace is a blast-radius boundary too.

Place on the tenant-isolation spectrum

This is shape 7 on the wiki's tenant-isolation spectrum — distinct from earlier shapes because the vendor, not the platform team, operates the boundary primitives:

# Shape Boundary Operated by
1 Shared account + JWT-only + app-layer enforcement App layer Platform
2 Shared account + per-tenant policy store + data-layer re-verification Multi-layer Platform
3 Account-per-tenant AWS account Platform (via AWS Organizations)
4 IAM-role-per-tenant via Cognito IAM credentials Platform
5 Shuffle-sharded compute pool Shuffle set Platform
6 Cluster-per-tenant in shared account ECS cluster Platform
7 Per-tenant workspace in third-party SaaS Vendor workspace Vendor

Why this shape exists

A multi-tenant platform that depends on a third-party SaaS for some non-core capability (marketing automation, payment processing, customer-support ticketing, observability) has three options for tenant isolation in that vendor:

  1. Single shared workspace + tenant tags on every record. Cheapest. Tenant isolation depends entirely on the vendor's tag-filtering logic + the platform's discipline at always passing the right tags. One missed tag is a data leak.
  2. Workspace-per-tenant. Vendor enforces the boundary at its API surface. Brand templates can be vendor-native (no per-call branding parameter passing). One retailer's misconfiguration doesn't pollute another's.
  3. Account-per-tenant in vendor's billing model. Per-tenant credit-card billing relationship; rarely viable operationally — vendors charge per workspace already, but accounts add legal/compliance overhead.

Workspace-per-tenant is the sweet spot when the vendor supports the workspace primitive: it gets vendor-enforced isolation without the per-tenant-account onboarding tax.

What the platform still has to build

The workspace primitive is necessary but not sufficient. The 2026-05-14 source documents the operational machinery Instacart has to build around the vendor's workspace abstraction:

  • Workspace provisioning automation — onboard a new retailer = create a workspace, configure sender identity, prime templates, allocate IPs.
  • Per-tenant routing — the CRM Service maps each send request to the correct retailer's workspace.
  • Template deployment across N workspaces — pushed via CI/CD from a metadata file rather than vendor-UI clickops.
  • Cross-workspace metric aggregation — operational dashboards (Datadog) and business reporting (Snowflake) need to roll up per-workspace data into one view.
  • IP-warming pipeline — vendor doesn't ramp on its own; platform automates it (see patterns/automated-ip-warming-with-deliverability-feedback).
  • Vendor abstraction — see patterns/vendor-abstraction-service-layer — the platform deliberately hides vendor-specific behavior so it can swap providers later.

Caveats and tradeoffs

  • Vendor-shaped scars. If the vendor's workspace model is weak (e.g. workspaces share rate limits, or workspace identity isn't really opaque), the boundary leaks. The platform inherits the vendor's boundary properties.
  • Cross-tenant operations are awkward. A platform-admin view of all retailers' campaigns requires either vendor-side admin permissions or N parallel API calls.
  • Quota cliffs. Vendors typically cap workspace count per account. Beyond the cap, the platform either pays for multiple vendor accounts or merges low-volume tenants.
  • Vendor lock-in. Workspaces are non-portable; migrating off the vendor means re-creating workspaces on a new provider. This is exactly why patterns/vendor-abstraction-service-layer is paired with workspace-per-tenant.

Seen in

Last updated · 542 distilled / 1,571 read