Arquitectura SaaS Laravel escalable
Casi todo SaaS Laravel empieza mono-tenant y añade una tabla de tenants después. Aguanta hasta que jobs, cachés y archivos se filtran. El aislamiento es una decisión de producto, no un middleware pegado al final.
El aislamiento es el producto
Trato la tenancy como frontera dura: datos, colas, almacenamiento y config. Un tenant_id no basta si un job ve las filas equivocadas.
En BROC ServiceOS la pregunta no es el paquete, sino qué pasa si A factura mientras se restaura B.
Colas, caché y archivos
Horizon, Redis y S3 no son decorado. Cada job lleva el tenant. Cada clave de caché está namespaced.
Si lo saltas, depurarás datos «aleatorios» en producción. Nunca lo son. Falta una frontera.
Billing junto al tenant
Los planes deben mapear límites que el producto aplica: asientos, sedes, volumen API — no un PDF de features. El billing vive junto al tenant.
Desde Tánger entrego SaaS Laravel así porque reescribir tras el segundo cliente sale más caro que aislar bien el día uno.
Ideas clave
- Decide el aislamiento antes de los paquetes.
- Jobs, caché y archivos deben llevar el tenant.
- Factura límites que de verdad aplicas.
FAQ
¿Paquete multi-tenant desde el día uno?
Usa un paquete solo cuando puedas describir el aislamiento: base, colas, archivos. El paquete no inventa una frontera que no diseñaste.
¿Una base o una por tenant?
Empieza con una base y scoping estricto. Separa después si compliance, restore o vecinos ruidosos lo exigen.