saas-architecture-deep-dive

SaaS 架构深入解析

掌握 SaaS 架构，并以资深专家的水准进行沟通。

主要工作流

1. 识别需求

用户说……	操作
“解释多租户”	查看 multi-tenancy-patterns.md
“设计 SaaS 系统”	前往决策框架（下文）
“集成支付/计费”	查看 billing-integration.md
“扩展我的系统”	查看 scaling-strategies.md
“解释我的架构”	查看 your-architecture-answers.md

---

2. 决策框架：设计 SaaS

步骤 1：需求

Preguntas clave:
- Cuantos tenants esperamos? (10, 100, 10000?)
- Que tan sensibles son los datos? (compliance requirements?)
- Tenants similares o muy diferentes en uso?
- Budget de infraestructura?

步骤 2：选择租户模式

POCOS TENANTS + DATOS SENSIBLES + ALTO BUDGET
→ SILO (database per tenant)

MUCHOS TENANTS + DATOS NO SENSIBLES + BAJO BUDGET
→ POOL (shared database, tenant_id)

BALANCE
→ BRIDGE (schema per tenant)

步骤 3：定义隔离边界

- Data isolation: como separar datos por tenant
- Compute isolation: recursos compartidos o dedicados
- Network isolation: VPCs, subnets separados?

步骤 4：计费模式

- Flat rate: simple, predecible
- Usage-based: justo, complejo de trackear
- Tiered: balance, feature gates
- Hybrid: base + overage

---

3. SaaS 核心模式

多租户（摘要）

模式	隔离性	成本	复杂度	适用场景
Silo	高	高	中	医疗保健、金融
Pool	低	低	低	通用 SaaS
Bridge	中	中	高	企业级 SaaS

详情请参阅 multi-tenancy-patterns.md。

租户上下文

// Middleware pattern
const tenantMiddleware = (req, res, next) => {
  const tenantId = req.headers['x-tenant-id'] || extractFromJWT(req);
  if (!tenantId) return res.status(401).json({ error: 'Tenant required' });
  req.tenant = tenantId;
  next();
};

// Query builder injection
const withTenant = (query, tenantId) => {
  return query.where('tenant_id', tenantId);
};

功能开关

// Feature flag pattern por plan
const features = {
  free: ['basic_reports'],
  pro: ['basic_reports', 'advanced_reports', 'api_access'],
  enterprise: ['basic_reports', 'advanced_reports', 'api_access', 'sso', 'audit_logs']
};

const hasFeature = (tenant, feature) => {
  return features[tenant.plan]?.includes(feature) ?? false;
};

---

4. 常见权衡

单体 vs 微服务

Monolito cuando:
- Equipo pequeno (<5 devs)
- Dominio no claramente separable
- Time-to-market prioritario

Microservicios cuando:
- Equipos independientes por servicio
- Scaling muy diferente por componente
- Diferentes stacks por servicio tienen sentido

SaaS 的 SQL vs NoSQL

SQL (PostgreSQL) cuando:
- Datos relacionales (users, orders, subscriptions)
- Transacciones importantes (pagos)
- Queries complejas con JOINs

NoSQL (MongoDB) cuando:
- Schemas muy variables por tenant
- Write-heavy workloads
- Document-centric data

同步 vs 异步处理

Sync cuando:
- Usuario espera resultado inmediato
- Operacion rapida (<500ms)
- Feedback importante para UX

Async cuando:
- Operaciones largas (emails, reports)
- Puede fallar y necesita retry
- No bloquea al usuario

---

5. SaaS 架构检查清单

DATA LAYER
[ ] Tenant isolation implementado
[ ] Backup strategy por tenant o global
[ ] Data retention policies definidas
[ ] Audit logging para compliance

APPLICATION LAYER
[ ] Tenant context en cada request
[ ] Feature flags por plan
[ ] Rate limiting por tenant
[ ] Error handling con tenant context

INFRASTRUCTURE
[ ] Scaling strategy definida
[ ] Monitoring por tenant
[ ] Cost allocation posible
[ ] Disaster recovery plan

BILLING
[ ] Subscription lifecycle manejado
[ ] Usage tracking si aplica
[ ] Webhook handlers para Stripe events
[ ] Dunning flow para pagos fallidos

---

参考资料

文件	内容	适用场景
multi-tenancy-patterns.md	详细介绍 Pool、Silo、Bridge	设计多租户
billing-integration.md	Stripe 订阅、webhook	集成计费
scaling-strategies.md	水平扩展、垂直扩展、分片	扩展系统
your-architecture-answers.md	HostelOS、Digitaliza 详解	展示你的经验