Resolución de tenant por ruta (path), no por subdominio

En lugar de asignar un subdominio DNS real a cada célula/tenant, se usa un único dominio real y se codifica la identidad de célula y tenant como segmentos de la URL.

Figura 2. Namespace por path sobre un único dominio real.

Frontend: andrescortes.dev/{celula}/{tenant}
API:      andrescortes.dev/api/{celula}/{tenant}/{recurso}

Ejemplo:  andrescortes.dev/api/alpha/proyecto-final/reservas

Un middleware en ASP.NET Core intercepta la petición antes del enrutamiento normal, parsea los segmentos {celula} y {tenant}, consulta (con caché en memoria/Redis) el catálogo para resolver la connection string correspondiente, y la expone al resto del pipeline mediante un servicio scoped (ITenantContext). En Next.js, el mismo namespace se resuelve con rutas dinámicas anidadas (app/[celula]/[tenant]/page.tsx).

Por qué así

No se otorgan subdominios DNS reales por dos razones prácticas: (1) evita depender de wildcard DNS y de emisión dinámica de certificados TLS por cada tenant creado, lo que sería infraestructura frágil y costosa de mantener; (2) el reverse proxy se simplifica a un único upstream y un único certificado, mientras toda la lógica de multi-tenencia queda contenida en la aplicación, donde es más fácil de testear, versionar y auditar. El aislamiento de namespace que pide el reto se logra igual, solo que a nivel de aplicación en vez de a nivel de red.

El nombre de tenant (slug) debe validarse con una expresión regular estricta (^[a-z0-9-]{3,30}$) antes de usarse en cualquier resolución de ruta, para evitar colisiones de nombres o intentos de path traversal.