Consultas de reporting sobre la base transaccional
La generación de reportes ejecuta consultas de gran volumen directamente sobre la misma base de datos utilizada por las operaciones diarias de ventas y stock.
CASO DE ESTUDIO / 01
Evaluación del Rendimiento. Java · Spring · PostgreSQL.
Una cadena de supermercados cuenta con un sistema centralizado para gestionar ventas, stock, almacenes y operaciones bancarias. El sistema es utilizado por las distintas sucursales y se encuentra integrado con las cajas de cada establecimiento, mientras que el acceso a las operaciones administrativas está restringido mediante un sistema de usuarios y permisos.
DESCUBRIMIENTO
Problema descrito por el cliente.
El equipo reporta que, al solicitar la generación de los reportes diarios, el sistema comienza a responder lentamente hasta quedar prácticamente bloqueado. Durante este proceso, otros usuarios tienen dificultades para continuar trabajando con normalidad. Además, se han registrado problemas recurrentes relacionados con el consumo de memoria de la base de datos, especialmente durante la ejecución de estos reportes.
ARQUITECTURA ACTUAL
Arquitectura actual del sistema
El sistema está construido sobre una arquitectura centralizada, donde la aplicación concentra las operaciones de ventas, stock, almacenes y generación de reportes sobre el mismo backend y la misma base de datos.
CLIENT
Frontend
Interfaz de usuarios
APPLICATION
Spring Boot
Ventas · Stock · Almacenes · Reportes
DATABASE
PostgreSQL
Datos transaccionales y reporting
ANÁLISIS
Hallazgos de la investigación
El análisis del flujo de ejecución permitió identificar varios puntos de impacto que explican el comportamiento observado durante la generación de reportes.
Consumo elevado de memoria durante los reportes
El procesamiento de grandes cantidades de información provoca un incremento significativo en el consumo de memoria durante la generación de reportes, afectando la capacidad de respuesta general del sistema.
Competencia entre operaciones transaccionales y reporting
Las operaciones críticas del negocio comparten recursos de procesamiento y acceso a datos con tareas de reporting, generando contención durante los períodos de mayor carga.
Falta de observabilidad
El sistema no cuenta con suficiente información sobre tiempos de respuesta, consumo de recursos y comportamiento de las consultas, dificultando la identificación temprana de degradaciones de rendimiento.
EXPLICACIÓN TÉCNICA
¿Como llegamos a dar con estos problemas?
El análisis se centró en seguir el flujo de generación de reportes desde la aplicación hasta la base de datos, observando el comportamiento del sistema bajo carga y revisando la implementación responsable del procesamiento de la información.
Seguimiento del flujo de ejecución
Se trazó el recorrido realizado por una solicitud de reporting, desde el frontend hasta la ejecución de las consultas en PostgreSQL. Esto permitió identificar que las solicitudes de reportes utilizan el mismo backend y los mismos recursos que las operaciones transaccionales.
Análisis de la implementación
La lógica de negocio y la generación de reportes se encuentran concentradas dentro de la misma aplicación Spring Boot. El procesamiento de grandes volúmenes de información se realiza dentro del flujo principal de la aplicación, sin una separación clara entre las operaciones transaccionales y las tareas de reporting.
Análisis del consumo de recursos
Durante la generación de reportes se observa un incremento significativo del consumo de memoria, asociado al procesamiento de grandes conjuntos de resultados. Esta carga adicional impacta tanto en la aplicación como en la capacidad de respuesta de la base de datos.
Identificación de la causa arquitectónica
El problema no se encuentra aislado en una única consulta o componente. La arquitectura actual permite que una tarea pesada de reporting comparta recursos con las operaciones críticas del sistema, provocando que una carga puntual termine afectando al resto de los usuarios.
ENTREGABLES
Diseñamos el cambio de arquitectura que queremos establecer.
La propuesta separa las operaciones críticas del negocio de la generación de reportes, permitiendo que ambas cargas evolucionen y escalen de manera independiente sin comprometer la disponibilidad del sistema transaccional.
CLIENT
Frontend
Interfaz de usuarios
API
API Gateway
Entrada y distribución de solicitudes
TRANSACTIONAL
Core
Ventas · Stock · Almacenes
DATABASE
PostgreSQL
Datos transaccionales
REPORTING
Reports
Procesamiento de reportes
REPORTING DATABASE
Reporting DB
Datos optimizados para reporting
El objetivo principal de la propuesta no es dividir el sistema por tecnología, sino aislar las cargas de trabajo que compiten por los mismos recursos.
PROPUESTA
Roadmap de implementación
La evolución propuesta se plantea de forma incremental, priorizando primero la visibilidad sobre el comportamiento del sistema y luego la separación de las cargas de trabajo.
01
FASE 1
Observabilidad
Incorporar métricas, logs y trazabilidad suficientes para identificar tiempos de respuesta, consumo de recursos y comportamiento de las consultas.
02
FASE 2
Optimización SQL
Revisar las consultas utilizadas por los reportes, analizar planes de ejecución y optimizar los accesos a los datos antes de introducir cambios estructurales mayores.
03
FASE 3
Separación del reporting
Separar progresivamente el procesamiento de reportes de las operaciones transaccionales y establecer una base de datos específica para las necesidades de reporting.
04
FASE 4
Evaluación posterior
Comparar el comportamiento del sistema antes y después de los cambios, verificando que las operaciones transaccionales mantengan tiempos de respuesta adecuados bajo carga.