Multi-Tenant SaaS, Identity & Platform Services — Interview Questions

How to use this lesson

Multi-tenancy is about isolation versus cost. Give a clear stance for each of:

• data isolation (the model per tier);
• tenant context propagation (from token to database);
• noisy neighbours (quotas);
• tenant-aware operations (onboarding, migrations, backups, billing).

Platform services (identity, config, flags, scheduling) share a theme: they are critical shared dependencies, so design them for high availability and safe degradation.

Q1. Design a multi-tenant SaaS platform.

Short answer:

• Tenant model: tenant (a hotel group), sub-units (properties), users with roles per tenant, and tiers (standard, enterprise).
• Isolation levels (often mixed by tier):
  • pool: shared infrastructure and database, with a tenant ID column. The cheapest; the most care is needed;
  • bridge: schema per tenant, or database per tenant, on shared compute;
  • silo: dedicated stack for big or regulated tenants.
• Tenant context:
  • resolved at the edge (from the JWT tenant_id claim, a subdomain or a header, validated against the token);
  • propagated through the calls (headers, Kafka headers, MDC for logs);
  • enforced in the data layer.
• Noisy neighbours: rate limits and quotas per tenant; separate queues or partitions for large tenants; fair-share scheduling for background jobs; per-tenant metrics.
• Operations:
  • automated onboarding (provisioning schema, configuration, IdP connection, seed data);
  • tenant-aware migrations (Flyway across many schemas, in batches);
  • per-tenant backup and restore and data export;
  • per-tenant configuration and feature flags;
  • usage metering for billing;
  • tenant offboarding with data deletion.
• Compliance: data residency (tenant pinned to a region), encryption (per-tenant keys for enterprise), and audit.

Q2. Design a multi-tenant SaaS database strategy.

Short answer:

• Shared tables:
  • put tenant_id in every table and every index (leading column), and in unique constraints;
  • enforce it with PostgreSQL Row-Level Security (current_setting('app.tenant_id')), or Hibernate 6 @TenantId, or filters. Belt and braces: application filters plus RLS;
  • shard by tenant_id when you outgrow one database (Citus, or application-level routing).
• Schema or database per tenant: Hibernate's multi-tenancy (MultiTenantConnectionProvider plus CurrentTenantIdentifierResolver), or Spring's AbstractRoutingDataSource, keyed by the tenant context. Watch the connection pools (per-database pools multiply connections; use PgBouncer).
• Hybrid: the pool for most tenants, and silo for the largest, behind the same routing abstraction.

ALTER TABLE booking ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON booking
  USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- per request/transaction: SET LOCAL app.tenant_id = '<tenant uuid>';

Q3. How do you ensure multi-tenant security?

Short answer:

• Authentication per tenant (each tenant's IdP through SSO, or a shared IdP with tenant claims).
• Every authorisation check includes the tenant: a user of tenant A must never access a resource of tenant B, even with a guessed ID. Guard against IDOR by loading resources scoped by tenant (findByIdAndTenantId), never by ID alone.
• Data-layer enforcement (RLS, @TenantId), so a missing filter in one query doesn't leak data.
• Tenant context comes from the validated token, not from a client-supplied header alone.
• Isolation in caches, search indices and files: the tenant is part of every cache key, index filter and object storage prefix (with IAM policies per prefix where possible).
• Encryption: TLS everywhere; encryption at rest; per-tenant keys (KMS) for enterprise tenants, which enables crypto-shredding on offboarding.
• Tenant-aware logs and audit; automated cross-tenant access tests in CI (a test suite that tries to access tenant B's data as tenant A).
• Admin and support access: just-in-time, audited, and ideally with the tenant's consent.

Common trap: relying on "the UI only shows your own data". An attacker calls the API directly with other IDs. Every query must be tenant-scoped on the server.

Q4. Design a multi-tenant JWT structure.

Short answer:

{
  "iss": "https://auth.example.com/",
  "sub": "user-8f2c",
  "aud": "booking-api",
  "exp": 1767225600, "iat": 1767224700, "jti": "b7e1…",
  "tenant_id": "t-4512",
  "org_units": ["hotel-101", "hotel-102"],
  "roles": ["RESERVATION_AGENT"],
  "scope": "bookings:read bookings:write",
  "amr": ["pwd", "mfa"]
}

• Short-lived access tokens (5–15 minutes), with refresh tokens (rotated, and stored securely).
• Signed with asymmetric keys (RS256 or ES256); services validate them with the IdP's JWKS endpoint (with key rotation through kid).
• Validate iss, aud, exp and the signature on every service; don't put sensitive data in it (JWTs are only encoded, not encrypted).
• Keep the token small: fine-grained permissions (per hotel) can be looked up by the service or policy engine, instead of embedding hundreds of claims.
• Users in several tenants: issue a token per selected tenant (the user switches tenants, and gets a new token), rather than listing all tenants' roles in one token.

Q5. Design an SSO authentication system.

Short answer:

• Protocols: OpenID Connect (on OAuth 2.0) for modern web and mobile apps; SAML 2.0 for enterprise identity providers (many corporate IdPs still use it).
• Components:
  • an identity provider or broker (Keycloak, Okta, Auth0, Entra ID, Cognito) that federates to each tenant's corporate IdP (identity brokering), plus local accounts, with MFA;
  • apps are OIDC clients using the authorization code flow with PKCE;
  • a central session at the IdP gives the SSO experience (logging in once for all apps);
  • Single logout (back-channel logout) where needed.
• Tenant discovery: route the user to the right IdP (home-realm discovery by email domain or subdomain).
• Provisioning: SCIM for user lifecycle (create, deactivate), or just-in-time provisioning on first login.
• Security: short token lifetimes, refresh token rotation, audience restriction, secure cookies (HttpOnly, Secure, SameSite), and signing-key rotation.
• Availability: the IdP is a critical dependency, so run it highly available, and make services validate tokens locally (JWKS caching), so they keep working through a brief IdP blip.

Learn it in depth → Design an Authentication System at Scale

Q6. Design a token revocation mechanism.

Short answer: JWTs are stateless, so they are valid until they expire. The options:

• Short access-token lifetimes (5–15 minutes) plus revocable refresh tokens (stored server-side, and rotated on use; reuse detection revokes the whole token family). This is the main mechanism.
• A denylist of revoked jti values (or "user X: tokens issued before time T are invalid") in Redis, with a TTL equal to the token's remaining lifetime. Services check it on each request (a fast local cache, updated through pub/sub).
• Token introspection (opaque tokens checked against the auth server) for high-security APIs: immediate revocation, at the cost of a network call (cached briefly).
• Events: on password change, logout-all, or account disable, publish a UserSessionsRevoked event, and services update their denylists.
• Key rotation as the "revoke everything" emergency option.

Q7. Design high-scale session management.

Short answer:

• Prefer stateless services: for APIs, use tokens (JWTs) and avoid server sessions entirely.
• When sessions are needed (server-rendered web apps, BFF patterns):
  • store them in a distributed store (Spring Session with Redis), so any instance can serve the user, instead of sticky sessions (which break on instance failure and scale unevenly);
  • keep the session data small (IDs, not object graphs);
  • set a TTL (idle and absolute timeouts);
  • rotate the session ID on login (session fixation);
  • use secure cookie attributes.
• The BFF pattern for single-page apps: the browser holds an HttpOnly session cookie; the backend-for-frontend keeps the OAuth tokens server-side. That's safer than storing tokens in localStorage.
• Scale: a Redis Cluster; sharding by session ID; replicas; and a plan for Redis failure (users re-authenticate).

Q8. Design centralized configuration management.

Short answer:

• The layers: defaults in code → environment configuration (Git-backed: Spring Cloud Config Server, Kubernetes ConfigMaps, AWS AppConfig, Consul) → secrets in a vault (HashiCorp Vault, AWS Secrets Manager, not in Git or plain ConfigMaps) → runtime feature flags.
• Principles:
  • configuration as code (versioned, reviewed, and auditable);
  • validation at load time (@ConfigurationProperties with @Validated), failing fast;
  • environment parity;
  • hierarchical overrides (global → region → service → tenant).
• Dynamic refresh: Spring Cloud Bus or @RefreshScope, or Kubernetes volume-mounted ConfigMaps that are watched. Only for settings that are safe to change live. Roll out config changes gradually, like code (config changes cause many outages).
• Availability: services cache the last known good config locally, and start with it if the config server is down.
• Secrets: dynamic, short-lived credentials (Vault database secrets engine), automatic rotation, least-privilege access, and audit.

Learn it in depth → Design a Centralized Configuration & Secrets System

Q9. How do you implement feature flags? Design a feature-toggle system.

Short answer:

• Flag types: release toggles (hide unfinished work; short-lived), experiment toggles (A/B tests), ops toggles / kill switches (turn off expensive features under load), permission toggles (per tenant or plan).
• Evaluation:
  • the SDK evaluates flags locally (in memory), from rules synced from the flag service. That means no network call per evaluation, and it keeps working if the flag service is down (with the last known values and safe defaults);
  • rules target users, tenants, percentages (consistent hashing of the user ID, so the same user always gets the same variant), regions or versions.
• Architecture:
  • a flag management UI and API (with audit and approvals for production);
  • storage (a database);
  • streaming updates to the SDKs (SSE or WebSockets) or polling;
  • an evaluation event stream for analytics.
• Tools: LaunchDarkly, Unleash, Flagsmith, or the OpenFeature standard API with a pluggable provider (a good way to avoid vendor lock-in in Java).
• Hygiene:
  • flags have owners and expiry dates;
  • remove the release flags after rollout (flag debt makes code hard to reason about);
  • test both paths;
  • never use flags to hold secrets.

boolean newPricing = featureClient.getBooleanValue("new-pricing-engine", false,
        new ImmutableContext(tenantId, Map.of("region", new Value("IN"))));
PriceBreakdown price = newPricing ? pricingV2.price(req) : pricingV1.price(req);

Learn it in depth → Design a Feature Flag System

Q10. Design an API version deprecation strategy.

Short answer:

1. Policy: publish a versioning and deprecation policy (for example, a minimum 6–12 months of notice for public APIs; a compatibility guarantee within a major version).
2. Avoid unnecessary versions: make additive, backward-compatible changes (new optional fields; tolerant readers) wherever possible.
3. Announce: changelog, email to the registered API clients, documentation, and HTTP headers on the old version (Deprecation and Sunset headers, plus a Link to the migration guide).
4. Measure: track who still calls the old version (API keys or client IDs from analytics); contact them directly.
5. Support the migration: a migration guide, SDK updates, a sandbox, and possibly a compatibility adapter that translates old requests to the new implementation.
6. Enforce gradually: brownouts (planned short periods where the old version returns errors, to find the forgotten clients), then retirement on the sunset date.
7. Internal APIs: consumer-driven contract tests show which consumers depend on which fields, so removals are safe.

Q11. Design a distributed scheduler.

Short answer:

• Requirements: jobs run on time, once (or at least once, with idempotent jobs), survive node failures, scale to many jobs, and have retries, history and monitoring.
• Simple options:
  • ShedLock plus @Scheduled (a lock in the database or Redis, so only one instance runs each job);
  • Quartz in clustered mode (JDBC job store, with row locks: SELECT … FOR UPDATE);
  • Kubernetes CronJobs for batch-style jobs.
• Designing a scheduler service at scale:
  • job store: a database table (job ID, schedule or cron, next run time, status, payload, owner);
  • trigger: scanner nodes poll next_run_time <= now using FOR UPDATE SKIP LOCKED, or partition the jobs by hash across nodes (with leader election, or consistent hashing);
  • claimed jobs are enqueued onto a queue (Kafka or SQS), and workers execute them;
  • leases with heartbeats: if a worker dies, the job is reclaimed after the lease expires. Jobs must be idempotent, because a run may be executed twice;
  • retries with backoff, a DLQ, timeouts, and a concurrency policy (skip, queue, or run in parallel if the previous run is still going);
  • time zones and DST handled explicitly (store cron expressions with a time zone);
  • history, metrics, alerting on missed or failed runs.
• Workflow engines (Temporal, Airflow, Camunda) for multi-step jobs with dependencies.

Learn it in depth → Design a Distributed Task Scheduler

Follow-up questions this topic invites — and their answers

Q: What is a noisy neighbour, and how do you mitigate it? A: One tenant's heavy usage degrading others on shared resources. Mitigate with per-tenant rate limits and quotas, resource isolation for large tenants (dedicated partitions, queues, or databases), fair scheduling, and per-tenant monitoring.

Q: Why store refresh tokens server-side if access tokens are stateless? A: So they can be revoked and rotated. Reuse detection (a refresh token used twice) reveals theft and lets you revoke the whole session family.

Q: What's the risk of long-lived feature flags? A: Combinatorial code paths that are hard to test and reason about, dead code, and surprising behaviour when a forgotten flag is flipped. Give release flags an expiry and remove them promptly.

Q: What are the Deprecation and Sunset HTTP headers? A: Response headers that tell clients an endpoint is deprecated (since a date) and when it will stop working. They are machine-readable, so clients and gateways can detect and report upcoming removals.