Multi-tenancy (equipos)
Todos los datos de negocio (clientes, vehículos, conductores, rutas, viajes, facturas…) pertenecen a un equipo (team). Un usuario puede ser miembro de varios equipos con roles distintos; tras el login, el frontend obliga a elegir equipo antes de entrar al dashboard.
Cómo se manda el equipo
Sección titulada «Cómo se manda el equipo»Depende del endpoint (consultar la referencia de cada uno):
- Path param — p. ej.
GET /teams/{teamId}/members. - Query param — p. ej.
GET /vehicles?teamId=<uuid>,GET /billing/subscription?teamId=X. - Body — en creaciones, p. ej.
POST /tripsincluyeteamId.
En todas las llamadas con teamId, la Lambda valida la membresía del usuario autenticado contra DynamoDB (get_user_membership) — mandar el teamId de un equipo ajeno produce 403, sin importar que el JWT sea válido.
| Rol | Puede |
|---|---|
OWNER |
Todo, incluida transferencia de propiedad y borrado del equipo |
ADMIN |
Gestión completa de recursos y miembros (sin transferir ownership) |
USER |
Operación diaria según el recurso; sin gestión de miembros ni billing |
Los endpoints administrativos (billing, invitaciones, cambio de roles, eliminación de miembros) exigen ADMIN u OWNER (require_team_admin).
Aislamiento físico
Sección titulada «Aislamiento físico»DynamoDB usa single-table design con partition keys TEAM#{teamId} — cada query de negocio parte de la PK del equipo, por lo que el aislamiento no depende de filtros en memoria sino del propio patrón de acceso. Los recursos soft-deleted (DeletedAt) se excluyen en cada query.