Que es
Domus Rentas es una plataforma de renta de propiedades en produccion: la cara publica es un sitio donde la gente busca casas amuebladas para estancias largas, ve fotos, precios y servicios incluidos, y agenda una cita. Por debajo, esa plataforma se construyo como un SaaS multi-tenant: cada inmobiliaria o administrador es un inquilino (tenant) aislado dentro del mismo sistema, con sus propiedades, sus agentes, sus contactos y su configuracion.
Pero lo interesante no es el CRUD de propiedades -- es como esta construido por dentro: no es un monolito, son nueve microservicios que se reparten el trabajo, cada uno con su propia responsabilidad, su propio framework y su propia base de datos logica.

Para quien es y que resuelve
Para una inmobiliaria o un administrador de propiedades, el dolor no es tener un formulario de "alta de propiedad" -- es que todo vive en lugares distintos: las propiedades en una hoja, los contactos en el telefono, las conversaciones en WhatsApp, los recordatorios en la cabeza de alguien. Domus junta todo eso en una sola plataforma donde cada cliente trabaja aislado del resto:
- Catalogo de propiedades con tipos, estados y agentes asignados.
- Notificaciones por email, SMS, push, WhatsApp, Telegram o dentro de la app.
- Multimedia de cada propiedad (fotos con marca de agua automatica).
- Metricas y reportes del negocio.
- Tareas programadas que corren solas (recordatorios, limpiezas, sincronizaciones).
Todo eso, separado por tenant: lo que ve y configura una inmobiliaria nunca se mezcla con el de otra.

La arquitectura: nueve microservicios
En lugar de un solo backend que lo hace todo, Domus parte el problema en servicios independientes. Un frontend Next.js actua de gateway: reescribe cada llamada al microservicio que corresponde, asi el navegador habla con una sola URL y por dentro el trafico se reparte.
Cada servicio se puede desplegar, escalar y actualizar por separado: si el chat recibe mucho trafico, se escala solo el chat, sin tocar el resto. Y cada uno sigue la misma arquitectura limpia por dentro -- modelos, servicios (logica de negocio) y routers separados -- asi el codigo de un servicio se lee igual que el de cualquier otro.
Poliglota: Django donde conviene, FastAPI donde el tiempo real importa
No todos los servicios necesitan lo mismo, asi que no todos usan el mismo framework:
- Django + DRF para lo que es CRUD y reglas de negocio con mucho modelo: auth, propiedades, agentes, administracion, multimedia, analytics y cron. El admin de Django y el ORM aceleran todo eso.
- FastAPI para lo que necesita concurrencia y baja latencia: las notificaciones (envios asincronos a multiples canales) y el servicio de chat por WebSocket -- este ultimo todavia en desarrollo. Async de punta a punta con SQLAlchemy.
La gracia de los microservicios es precisamente esa: cada servicio elige la herramienta adecuada sin obligar a todo el sistema a casarse con una sola.
Multi-tenant de verdad
Ser "multi-tenant" no es solo poner un tenant_id en una tabla. En Domus, el
admin-service centraliza la configuracion por tenant -- ajustes, SMTP, plantillas
de correo -- de modo que cada cliente personaliza su instancia sin afectar a los demas,
y los servicios consultan esa configuracion para comportarse distinto segun el tenant.
El aislamiento es una propiedad del sistema, no un campo que alguien recuerda filtrar.
El panel: gestion del lado SaaS
Sobre esos microservicios se monta el panel donde cada tenant administra su negocio: un dashboard con el resumen, la gestion del catalogo, el alta de propiedades y las metricas -- todo sirviendose de los servicios de abajo a traves del gateway.




Stack
- Backend (CRUD + dominio): Django + Django REST Framework -- auth, propiedades, agentes, admin, media, analytics, cron.
- Backend (tiempo real): FastAPI con SQLAlchemy async -- chat (WebSocket) y notificaciones multicanal.
- Frontend / gateway: Next.js, que reescribe cada llamada al microservicio correspondiente.
- Datos: PostgreSQL como base principal y Redis para cache y mensajeria.
- Infra: Docker -- cada servicio en su contenedor, orquestados juntos.
La leccion
Partir un sistema en microservicios no es gratis: hay mas piezas que coordinar, mas despliegues, mas observabilidad que cuidar. Pero para un SaaS multi-tenant que tiene que crecer por partes -- mas chat aqui, mas reportes alla -- pagar ese costo compra dos cosas dificiles de conseguir en un monolito: escalar solo lo que lo necesita y elegir la herramienta correcta para cada problema (Django para el dominio, FastAPI para el tiempo real) sin que una decision arrastre a todo el sistema.