Domus Rentas: de un sitio de rentas a un SaaS multi-tenant en 9 microservicios

Caso de estudio de Domus Rentas, una plataforma de renta de propiedades en produccion, y su evolucion a un SaaS multi-tenant construido como una arquitectura de 9 microservicios poliglota -- Django donde conviene, FastAPI donde el tiempo real importa -- con un frontend Next.js que actua de gateway. PostgreSQL, Redis y Docker.

portfolioRepo Privado2026-06-25
djangofastapinextjspostgresqlredisdocker

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.

Pagina principal de Domus Rentas: hero con casas para renta de larga estancia y navegacion a propiedades y agendar cita
La cara publica del producto en produccion: el sitio donde se buscan y agendan rentas.

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.

Listado publico de propiedades en Domus Rentas: tarjetas con foto, precio mensual, recamaras, banos, metros y servicios incluidos
El catalogo publico: cada propiedad con foto (marca de agua automatica del media-service), precio, caracteristicas y servicios incluidos.

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.

Frontend Next.jsgateway: rewrites a cada servicioDJANGO + DRFFASTAPIauthJWT, usuarios, rolespropertiespropiedadesagentsagentes inmobiliariosadminconfig por tenantmediaarchivos, watermarkanalyticsmetricas, reportescrontareas programadaschatWebSocket, tiempo realnotificationsemail, push, WhatsApp...PostgreSQLRedis
Nueve servicios, dos frameworks, un gateway. El frontend Next.js reescribe cada peticion al servicio que corresponde; abajo, PostgreSQL y Redis compartidos.

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.

Dashboard del panel SaaS con tarjetas de resumen: propiedades, conversaciones activas, vistas totales y citas pendientes
El dashboard del tenant (datos demo): resumen de propiedades, vistas y actividad, alimentado por varios servicios a la vez.
Gestion de propiedades en el panel: tabla con precio, estado, vistas y acciones por propiedad
Gestion del catalogo (datos demo): cada propiedad con su precio, estado (disponible, inactiva, borrador) y vistas -- servido por properties-service.
Analytics del panel: vistas totales, leads generados, tasa de conversion, propiedades mas vistas y fuentes de trafico
Analytics (datos demo): leads, conversion, propiedades mas vistas y fuentes de trafico -- el trabajo de analytics-service.
Formulario de alta de propiedad con informacion basica, caracteristicas y ubicacion
Alta de una propiedad: informacion basica, caracteristicas y ubicacion, que terminan en properties-service y media-service.

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.

Te late algo similar?

Cuentame tu proyecto por WhatsApp

WhatsApp