1---2name: multi-tenancy-architect3description: Design tenant isolation, data partitioning, and SaaS patterns.4---5
6# Multi Tenancy Architect
7
8## Purpose
9- Design tenant isolation, data partitioning, and SaaS patterns.
10
11## Preconditions
12- Access to system context (repos, infra, environments)
13- Confirmed requirements and constraints
14- Required approvals for security, compliance, or governance
15
16## Inputs
17- Problem statement and scope
18- Current architecture or system constraints
19- Non-functional requirements (performance, security, compliance)
20- Target stack and environment
21
22## Outputs
23- Design or implementation plan
24- Required artifacts (diagrams, configs, specs, checklists)
25- Validation steps and acceptance criteria
26
27## Detailed Step-by-Step Procedures
281. Clarify scope, constraints, and success metrics.
292. Review current system state, dependencies, and integration points.
303. Select patterns, tools, and architecture options that match constraints.
314. Produce primary artifacts (docs/specs/configs/code stubs).
325. Validate against requirements and known risks.
336. Provide rollout and rollback guidance.
34
35## Decision Trees and Conditional Logic
36- If compliance or regulatory scope applies -> add required controls and audit steps.
37- If latency budget is strict -> choose low-latency storage and caching.
38- Else -> prefer cost-optimized storage and tiering.
39- If data consistency is critical -> prefer transactional boundaries and strong consistency.
40- Else -> evaluate eventual consistency or async processing.
41
42## Error Handling and Edge Cases
43- Partial failures across dependencies -> isolate blast radius and retry with backoff.
44- Data corruption or loss risk -> enable backups and verify restore path.
45- Limited access to systems -> document gaps and request access early.
46- Legacy dependencies with limited change tolerance -> use adapters and phased rollout.
47
48## Tool Requirements and Dependencies
49- CLI and SDK tooling for the target stack
50- Credentials or access tokens for required environments
51- Diagramming or spec tooling when producing docs
52
53## Stack Profiles
54- Use Profile A, B, or C from `skills/STACK_PROFILES.md`.
55- Note selected profile in outputs for traceability.
56
57## Validation
58- Requirements coverage check
59- Security and compliance review
60- Performance and reliability review
61- Peer or stakeholder sign-off
62
63## Rollback Procedures
64- Revert config or deployment to last known good state.
65- Roll back database migrations if applicable.
66- Verify service health, data integrity, and error rates after rollback.
67
68## Success Metrics
69- Measurable outcomes (latency, error rate, uptime, cost)
70- Acceptance thresholds defined with stakeholders
71
72## Example Workflows and Use Cases
73- Minimal: apply the skill to a small service or single module.
74- Production: apply the skill to a multi-service or multi-tenant system.