skills.rest
nguyenpv1980-wq
nguyenpv1980-wqCOMMUNITY
Explore all skills by this author →
GitHub

multi-tenant-data-architect

Design tenant-safe data-layer architecture across databases, caches, search indexes, and vector stores.

2|Updated Jul 6, 2026
Search Tags:#scoping#database design#multi-tenant#data architecture#migration planning#tenant isolation
One-click install
npx skills add https://github.com/nguyenpv1980-wq/Project-Aegis --skill multi-tenant-data-architect
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: multi-tenant-data-architect
Source: https://github.com/nguyenpv1980-wq/Project-Aegis/tree/main/.claude/skills/multi-tenant-data-architect
Command: npx skills add https://github.com/nguyenpv1980-wq/Project-Aegis --skill multi-tenant-data-architect

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you design how tenant data is stored, scoped, migrated, and protected across databases, caches, search indexes, vector stores, and other persistence layers in a multi-tenant system. It prevents ambiguous tenancy boundaries, unsafe client-supplied tenant context, and incomplete isolation designs that can lead to cross-tenant leakage.

Core Features & Use Cases

  • Per-store scoping decisions: Choose and justify pooled, schema-per-tenant, database-per-tenant, or mixed strategies for each storage layer.
  • Tenant-context propagation: Define how tenant identity is derived server-side and carried safely into queries and jobs.
  • Ownership and lifecycle mapping: Classify data as tenant-owned, shared/reference, or platform, and plan suspend, offboard, and purge behavior across stores.
  • Migration and isolation planning: Produce expand-backfill-verify-enforce-contract migration steps, rollback paths, and a data-layer isolation test matrix.
  • Use case: A team adding Redis and search to an existing Postgres app can use this Skill to design tenant-safe scoping for all stores and plan a reversible retrofit.

Quick Start

Ask the skill to design tenant-scoped storage for your app, including per-store isolation choices, server-derived tenant context propagation, lifecycle handling, and a verified migration plan.

Frequently Asked Questions about multi-tenant-data-architect

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design tenant isolation for a multi-tenant application across multiple storage layers?▼

Designing tenant isolation requires choosing pooled, schema-per-tenant, or database-per-tenant strategies for each storage layer, ensuring tenant context is derived server-side and safely propagated into queries and jobs to prevent cross-tenant data leakage.

What is the best way to retrofit tenant scoping when adding Redis and search indexes to an existing Postgres app?▼

Retrofitting tenant scoping involves defining per-store isolation choices for new caches and search indexes, establishing server-derived tenant binding, and planning a reversible migration path to safely backfill and verify tenant boundaries.

How does server-derived tenant context propagation prevent cross-tenant data leakage?▼

Server-derived tenant context propagation prevents leakage by binding tenant identity securely on the server side rather than trusting client-supplied data, ensuring every query, job, and vector store interaction is automatically scoped to the correct tenant.

What steps are needed to plan a tenant data migration or re-sharding without downtime?▼

A safe tenant data migration requires expand-backfill-verify-enforce-contract steps, rollback-aware migration paths, and a data-layer isolation test matrix to verify no cross-tenant leakage occurs during the re-sharding process.

Do I need a lifecycle mapping for tenant-owned data when offboarding a tenant?▼

Yes, you need ownership classification to define tenant-owned, shared, and platform data, enabling you to plan suspend, offboard, and purge behaviors that safely remove tenant data across all active stores.

When should I use a mixed multi-tenant database strategy instead of a single isolation model?▼

A mixed multi-tenant strategy is necessary when different storage layers have varying isolation requirements, allowing you to justify pooled, schema-per-tenant, or database-per-tenant models per store based on specific tenant data sensitivity and scale needs.

Related Skills

Explore More Software Engineering Skills→
marquesfelipmarquesfelip

tenant-file-isolation

Design tenant-level file namespace isolation in multi-tenant SaaS object storage.

Community
Advanced
himanshu231204himanshu231204
2

database-migrations

Plan zero-downtime PostgreSQL and MySQL schema migrations with expand-contract strategies.

Community
Advanced
marquesfelipmarquesfelip

tenant-context-propagation

Propagate and validate tenant context across HTTP requests and background jobs.

Community
Advanced
zinohomezinohome
1

multi-tenant-safety-checker

Enforce PostgreSQL Row Level Security policies for multi-tenant data isolation.

Community
Advanced