Skip to main content

Arquitectura del sistema

Plataforma Database-Centric de hosting de bases de datos para desarrolladores.

Stack: ASP.NET Core (.NET 10) · Next.js (pnpm) · SQL Server 2022 · Docusaurus

Este documento describe la arquitectura propuesta para el reto "Database-Centric Architecture", donde la lógica de negocio reside íntegramente en SQL Server (Stored Procedures, Views y Functions), dejando al backend un rol exclusivo de mediador, despachador y asegurador de la comunicación.

Resumen ejecutivo​

La plataforma se organiza en dos planos claramente separados:

  • Control Plane: una base de datos catálogo que sabe qué células y tenants existen, sus cuotas, su TTL y sus rutas.
  • Data Plane: N bases de datos SQL Server, una por cada tenant, aisladas entre sí y con el 100% de su lógica de negocio en Stored Procedures/Views/Functions.

El backend ASP.NET Core actúa exclusivamente como mediador: resuelve a qué base de datos conectarse, aplica autenticación, autorización y rate limiting, invoca el Stored Procedure correspondiente con parámetros tipados, y devuelve el resultado. No hay reglas de negocio, cálculos ni validaciones complejas en C#.

En lugar de asignar subdominios DNS reales a cada célula/tenant (lo que exigiría wildcard DNS, certificados TLS dinámicos y gestión de zonas), el aislamiento de namespace se resuelve mediante rutas de path sobre un único dominio real, y la autenticación se separa en dos flujos independientes: usuarios normales (login/registro público, acceso restringido a su propio tenant) y superadmin (login exclusivo, sin autorregistro, con visibilidad total del catálogo).

Filosofía de arquitectura: Database-Centric​

El reto invierte el paradigma tradicional: en vez de que el backend procese reglas de negocio y la base de datos solo persista datos, aquí la base de datos es el componente "inteligente" y el backend es "tonto". Esto se traduce en reglas concretas de diseño:

  • Toda validación compleja, cálculo o asignación de permisos se implementa en Stored Procedures.
  • Las consultas complejas se exponen como Views, nunca como LINQ/SQL construido en el backend.
  • Las transformaciones y cálculos reutilizables se implementan como Functions de SQL Server.
  • El backend solo recibe la petición HTTP, la traduce a una llamada de SP/View con parámetros tipados, y estructura la respuesta.
Por qué así

Centralizar la lógica en la base de datos garantiza que, sin importar cuántos backends o lenguajes distintos elija cada célula en el futuro (el reto permite "framework a elección"), las reglas de negocio se mantienen consistentes y no pueden ser bypaseadas conectándose directamente a la base de datos. También simplifica la auditoría de seguridad: todo el código relevante vive en un solo lugar (los SPs), no está disperso entre distintos backends de distintas tecnologías.

En esta sección​

Stack tecnológico​

ComponenteTecnología
Motor de base de datosMicrosoft SQL Server 2022
BackendASP.NET Core (.NET 10) + Dapper
FrontendNext.js (gestionado con pnpm)
DocumentaciónDocusaurus
Jobs en backgroundHangfire (aprovisionamiento y TTL)
Reverse proxyNginx / Traefik (upstream único, sin wildcard DNS)

Conclusión​

La combinación de database-per-tenant, resolución por path en lugar de subdominios reales, repositorio con DIP invocando exclusivamente Stored Procedures/Views/Functions, y dos flujos de autenticación completamente separados para usuarios y superadmin, cumple la regla de oro del reto (backend tonto, base de datos inteligente) sin sacrificar operabilidad ni seguridad. La arquitectura queda lista para escalar a N células sin requerir infraestructura DNS adicional, y con puntos de control claros para cuotas, TTL y aislamiento de datos.