Reestructuración del Servidor Backend para Interoperabilidad, Escalabilidad y Seguridad a través de APIs Bien Diseñadas

doi:10.22167/2675-6528-202601350

19 de octubre de 2026

Reestructuración del Servidor Backend para Interoperabilidad, Escalabilidad y Seguridad a través de APIs Bien Diseñadas

Reestructuración del Servidor Backend para Interoperabilidad, Escalabilidad y Seguridad a Través de APIs Bien Diseñadas

Rariman Lara Silva da Rocha; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202601350

Artículo elaborado por la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege orientada a la síntesis y redacción.

Resumen

El presente estudio propuso e implementó una arquitectura backend orientada a APIs para sistemas de telemetría de equipos, con el objetivo de mejorar el rendimiento, la escalabilidad y la organización de los datos. Inicialmente, se realizó un análisis de las limitaciones de enfoques basados exclusivamente en bases de datos analíticas para aplicaciones en tiempo real, que evidenciaron problemas de latencia y acoplamiento con el front-end. A partir de este diagnóstico, se desarrolló una arquitectura híbrida, que separó datos analíticos y transaccionales, y se introdujo un proceso de materialización de datos para consolidar información de la telemetría en un modelo optimizado para consulta. Paralelamente, se construyó una API REST bajo el estándar Backend for Frontend (BFF), contemplando la definición de rutas, autenticación (OAuth2 y JWT), versionamiento y documentación automatizada (Swagger/OpenAPI). Se elaboraron reglas de negocio para la gestión de usuarios, dispositivos y flujos operativos, y se implementaron pruebas unitarias exhaustivas para la validación de autenticación, idempotencia de métodos HTTP y paginación. Los resultados demostraron una reducción significativa en el tiempo de respuesta de las consultas, un aumento en la confiabilidad de las operaciones y la conformidad de la API con las buenas prácticas de diseño y seguridad. El enfoque proporcionó una base estructurada para la toma de decisiones y la evolución del sistema, optimizando el consumo de información por parte de los clientes y la utilización eficiente de los recursos computacionales, contribuyendo a la sostenibilidad y la confianza del ecosistema digital.

Palabras clave: Autenticación; Confiabilidad; Desempeño; Materialización de datos; Telemetría.

1. Introducción

El escenario tecnológico contemporáneo se caracteriza por la proliferación de sistemas distribuidos y la expansión del Internet de las Cosas (IoT), impulsando la generación y el consumo masivo de datos. En este contexto, la telemetría de equipos asume un papel fundamental, permitiendo el monitoreo remoto y la recolección continua de información operativa crítica. Miles de módulos en campo, en diversos sectores industriales, generan un volumen significativo de datos, lo que impone desafíos considerables en términos de escalabilidad, procesamiento y almacenamiento (Newman, 2021). Para viabilizar la comunicación y la integración eficiente entre dispositivos y aplicaciones, las Interfaces de Programación de Aplicaciones (APIs) han emergido como elementos arquitectónicos indispensables. La arquitectura Representational State Transfer (REST), propuesta por Fielding (2000), se ha consolidado como paradigma dominante para el diseño de APIs web, promoviendo estandarización, simplicidad y capacidad de expansión. La literatura y la práctica de mercado reiteran la importancia de las APIs como cimiento para ecosistemas digitales abiertos, facilitando la interacción entre aplicaciones (Newman, 2015; Fowler, 2019). La demanda por sistemas de telemetría robustos y responsivos exige, por lo tanto, una infraestructura de backend que gestione grandes volúmenes de datos de forma ágil y segura.

A pesar de la ubicuidad de las APIs, la concepción de interfaces bien estructuradas y seguras sigue siendo un desafío complejo. Una API, según la definición del Institute of Electrical and Electronic Engineers (IEEE, 2021), es una interfaz de software que establece un conjunto de funciones y protocolos para la comunicación entre componentes de un sistema, promoviendo la interoperabilidad y la modularización. El estilo arquitectónico REST, por su parte, se basa en la manipulación de recursos identificados por URLs y en el uso de operaciones estandarizadas, como los métodos HTTP, enfatizando la ausencia de estado y la separación entre cliente y servidor (Fielding, 2000). Este enfoque contrasta con modelos como las Llamadas a Procedimientos Remotos (RPC) (Birrel y Nelson, 1984) y SOAP (World Wide Web Consortium, 2007). Para garantizar la sostenibilidad y la usabilidad, Zimmermann et al. (2017) resaltan la necesidad de prácticas de gobernanza, versionado, autenticación robusta (OAuth2 y JWT) y documentación automatizada (Swagger/OpenAPI). Madden (2020) complementa, destacando que la seguridad debe ser intrínseca al diseño de la API, incluyendo la validación rigurosa de datos y el monitoreo continuo.

La elección de la arquitectura de backend es crucial para el rendimiento y la escalabilidad de los sistemas de telemetría. Las arquitecturas monolíticas, donde todas las funcionalidades se implementan como una única unidad, pueden presentar limitaciones en entornos de alta demanda (Newman, 2020). Por el contrario, las arquitecturas basadas en microservicios, que dividen el sistema en servicios autónomos que se comunican a través de APIs, ofrecen mayor flexibilidad y escalabilidad (Newman, 2021). En el contexto de la telemetría, la persistencia de datos a menudo implica bases de datos del tipo Online Analytical Processing (OLAP), optimizadas para grandes volúmenes y consultas analíticas complejas. Sin embargo, el uso exclusivo de bases de datos OLAP para satisfacer aplicaciones en tiempo real, que demandan respuestas transaccionales rápidas, puede resultar en problemas de latencia y acoplamiento excesivo con las capas de presentación, impactando la experiencia del usuario. Para mitigar estos desafíos, la materialización de datos surge como una estrategia eficaz, consolidando información de telemetría en un modelo optimizado para la consulta, separando cargas analíticas de las operacionales. Adicionalmente, el patrón Backend for Frontend (BFF) permite que la API se adapte a las necesidades específicas de los clientes, optimizando el consumo de información y la utilización de los recursos.

El análisis de arquitecturas de backend para sistemas de telemetría frecuentemente revela cuellos de botella de latencia en consultas en tiempo real y acoplamiento excesivo con el front-end, debido al uso exclusivo de bases de datos analíticas para demandas operacionales. Tales limitaciones comprometen el rendimiento, la escalabilidad y la organización de los datos, además de introducir riesgos de seguridad por la ausencia de buenas prácticas de diseño de APIs. El presente estudio se justifica por la necesidad de desarrollar una solución que supere estas deficiencias, proporcionando un ambiente más eficiente y confiable. De esta forma, el objetivo principal de este trabajo es proponer e implementar una arquitectura backend orientada a APIs para sistemas de telemetría de equipos, con el fin de mejorar el rendimiento, la escalabilidad, la organización de los datos y la seguridad de las operaciones.

2. Material y Métodos

La investigación adoptó una metodología aplicada, con un enfoque cualitativo y descriptivo, centrada en el análisis e implementación de buenas prácticas de diseño y gobernanza de Interfaces de Programación de Aplicaciones (APIs). Este estudio fue concebido como un caso práctico, con el objetivo de reestructurar un servidor backend para sistemas de telemetría de equipos. El objetivo central consistió en investigar y aplicar directrices para modernizar la integración entre dispositivos en campo y sistemas web, buscando mejorar el rendimiento, la escalabilidad y la seguridad. La naturaleza aplicada de la investigación permitió la validación práctica de las soluciones propuestas en un entorno operativo real, contribuyendo a la resolución de un problema tecnológico específico.

El estudio se llevó a cabo en una gran empresa, fabricante de equipos médicos, ubicada en el estado de Rio Grande do Sul, Brasil. La investigación se desarrolló específicamente en el área de Ingeniería de Proyectos e Investigación y Desarrollo (I+D), departamento responsable del ciclo completo de desarrollo de productos, incluyendo aspectos mecánicos, de hardware y software. El período de realización del trabajo correspondió al año 2026, según la fecha de presentación del Trabajo de Fin de Curso. La unidad de análisis consistió en la arquitectura de backend existente y en la propuesta de reestructuración para sistemas de telemetría de equipos, con el objetivo de mejorar su interoperabilidad, escalabilidad y seguridad.

Dado el carácter del estudio de caso, no existió una población o muestra definida en el sentido estadístico tradicional. La investigación se centró en la arquitectura de backend de un sistema de telemetría existente en la empresa, que gestionaba datos de miles de módulos de equipos en campo. La unidad de análisis fue el propio sistema de backend, con foco en sus limitaciones de rendimiento y acoplamiento con el front-end. Los criterios de selección para el alcance del estudio fueron las deficiencias identificadas en la arquitectura legada, que justificaron la necesidad de una reestructuración orientada a APIs para optimizar el rendimiento y la seguridad.

La recolección de datos se inició con una exhaustiva investigación bibliográfica, realizada en las bases de datos Google Scholar y ACM Digital Library. Se utilizaron palabras clave como “API design”, “API architecture”, “RESTful APIs”, “microservices architecture”, “API governance”, “API versioning” y “API security” para identificar publicaciones relevantes. La selección de los artículos para lectura en profundidad se basó en la relevancia y la adherencia al tema de arquitectura y diseño de APIs. Adicionalmente, se consultaron libros y tesis de referencia en el área, incluyendo la tesis de Fielding (2000) sobre arquitectura REST y el libro de Richardson et al. (2007) sobre la implementación de servicios RESTful, que fundamentaron los conceptos y directrices adoptados.

Tras la revisión bibliográfica, se procedió al diagnóstico técnico del entorno de backend existente en la empresa. Este diagnóstico tuvo como objetivo identificar la estructura actual del servidor, los patrones de integración empleados, las limitaciones de interoperabilidad y los puntos críticos de fallo relacionados con la escalabilidad y la seguridad de las comunicaciones entre dispositivos y sistemas. A partir de este análisis, se elaboró un diagrama C4, que representó la arquitectura propuesta para la reestructuración del backend. Este diagrama detalló los componentes, contenedores y flujos de integración actualizados, sirviendo como herramienta comparativa para evidenciar las mejoras esperadas en términos de interoperabilidad, escalabilidad y seguridad de la solución.

Basado en las buenas prácticas identificadas en la literatura y las demandas del entorno estudiado, se desarrolló un nuevo modelo de arquitectura backend orientado a APIs. El desarrollo se centró en la capa de servicios, implementando una API REST bajo el estándar Backend for Frontend (BFF). Esta etapa implicó la concepción de endpoints y reglas de negocio específicas para atender a las diferentes aplicaciones de frontend. Se definieron estándares de autenticación, control de versiones y la creación de documentación automatizada, con el objetivo de facilitar la integración y el mantenimiento del sistema, garantizando que la API fuera robusta y adaptable a las necesidades de los clientes.

La estructuración de los endpoints de la API siguió una convención de rutas estandarizada, compuesta por un prefijo técnico (/api), la identificación del canal consumidor (como /web o /mobile), un versionado explícito (/v1) y la segmentación por dominio funcional (por ejemplo, /auth y /users). Este enfoque se adoptó para reducir el acoplamiento entre los clientes, optimizar la organización de la documentación de la API y permitir la evolución independiente de los contratos expuestos. La Tabla 1 presenta ejemplos detallados de endpoints de la API, ilustrando la aplicación de esta convención por canal consumidor, versión y dominio funcional, facilitando la comprensión de la estructura implementada.

Tabla 1. Ejemplos de puntos finales de la API

Punto final	Vía	Versión	Dominio	Finalidad
/api/web/v1/auth/login	Web	v1	Autenticación	Realizar autenticación en la web
/api/web/v1/users/me	Web	v1	Usuarios	Devolver datos del usuario autenticado en la web
/api/web/v1/devices/{id}/details/	Web	v1	Equipos	Devolver detalles del equipo #id en la web
/api/web/v1/devices/locations/?page=1&page_size=5000	Web	v1	Equipos	Devolver última ubicación de los equipos usando paginación en la web
/api/mobile/v1/auth/login	Móvil	v1	Autenticación	Realizar autenticación en el móvil
/api/mobile/v1/users/me	Móvil	v1	Usuarios	Devolver datos del usuario autenticado en el móvil
/api/mobile/v1/devices/{id}/details/	Móvil	v1	Equipos	Devolver detalles del equipo #id en el móvil
/api/mobile/v1/devices/locations/?page=1&page_size=5000	Móvil	v1	Equipos	Devolver última ubicación de los equipos usando paginación en el móvil

Fuente: Datos originales de la investigación

Tras la implementación de la arquitectura, se llevó a cabo una rigurosa etapa de pruebas y validaciones, abarcando aspectos funcionales, de rendimiento y de seguridad de la API. Las pruebas funcionales se diseñaron para verificar la adherencia de los endpoints a la documentación Swagger/OpenAPI, incluyendo campos obligatorios, tipos de datos, códigos HTTP y mensajes de error estandarizados. También se evaluó la idempotencia de los métodos GET, PUT y DELETE, la consistencia de la paginación y filtros, y la robustez de los mecanismos de autenticación y autorización basados en JSON Web Tokens (JWT). La validación del sistema se guió por criterios de aceptación bien definidos, garantizando la fiabilidad y la conformidad con los requisitos establecidos.

La planificación de los casos de prueba implicó la identificación y organización de escenarios de evaluación, detallando datos de entrada, condiciones de ejecución y resultados esperados para cada uno. Se contemplaron tanto escenarios positivos, que verificaban el comportamiento correcto del sistema, como escenarios negativos, enfocados en la validación del tratamiento de errores y excepciones. El alcance de las pruebas se delimitó cuidadosamente para priorizar funcionalidades y componentes críticos, con especial atención a las rutas de autenticación, control de acceso y manipulación de datos. Este enfoque garantizó que los puntos de mayor impacto en la seguridad y el funcionamiento general de la aplicación fueran evaluados exhaustivamente.

Las pruebas se implementaron de forma automatizada utilizando la herramienta `pytest`, permitiendo la ejecución repetitiva, estandarizada y consistente de los escenarios definidos. Esta automatización facilitó la detección temprana de fallos y la validación continua de las funcionalidades a lo largo del desarrollo, contribuyendo a la robustez y calidad del sistema. Los casos de prueba, detallados en los apéndices del trabajo, abarcaron autenticación de usuarios, flujo de tokens, idempotencia de los métodos HTTP PUT y DELETE, y paginación de resultados. El análisis de los datos recopilados durante las pruebas se realizó mediante la comparación de los resultados obtenidos antes y después de la reestructuración, utilizando tablas y gráficos para medir el impacto en la eficiencia operativa y en la sostenibilidad de la arquitectura de APIs.

El análisis de los datos de prueba se centró en la verificación de la conformidad de la API con los requisitos funcionales y de seguridad. Para la autenticación, se evaluó la correcta validación de usuarios, el manejo de solicitudes inválidas y la consistencia de las respuestas. En el flujo de tokens, se verificó la generación, validación, renovación y expiración de los tokens de acceso, además del manejo de usos indebidos. Se analizó la idempotencia de los métodos PUT y DELETE para garantizar la consistencia del estado de los recursos después de múltiples ejecuciones. Finalmente, se probó la paginación en cuanto a navegación, control de elementos por solicitud y manejo de valores inválidos, asegurando la previsibilidad y coherencia de los resultados.

Este estudio, de naturaleza técnica y enfocado en la reestructuración de una arquitectura de software, no involucró la participación de seres humanos ni la recopilación de datos sensibles, por lo tanto, no requirió la aplicación de procedimientos éticos formales. En cuanto a las limitaciones metodológicas, el trabajo se centró en un estudio de caso específico, lo que puede restringir la generalización directa de los resultados a otros contextos organizacionales o sistemas de telemetría con características sustancialmente diferentes. Sin embargo, el enfoque detallado y la validación práctica de la solución propuesta ofrecen un modelo replicable y adaptable para escenarios similares, contribuyendo con un marco de buenas prácticas.

3. Resultados y Discusión

La presente sección de Resultados y Discusiones detalla los hallazgos de la investigación, comenzando con la contextualización de los principios y métodos para el diseño de APIs, seguida por el análisis de la arquitectura legada, la proposición de la nueva arquitectura y la presentación de los resultados de las pruebas unitarias. El objetivo central fue investigar y aplicar buenas prácticas de diseño y gobernanza de APIs para reestructurar un servidor backend de telemetría, con el fin de mejorar el rendimiento, la escalabilidad y la seguridad. La metodología aplicada, de naturaleza cualitativa y descriptiva, permitió la validación práctica de las soluciones en un entorno operativo real, proporcionando un marco de buenas prácticas para escenarios tecnológicos similares.

La comprensión de las Interfaces de Programación de Aplicaciones (APIs) es fundamental para la integración de sistemas modernos. Según el Institute of Electrical and Electronic Engineers (IEEE, 2021), una API es una interfaz de software que establece un conjunto de funciones, métodos y protocolos, permitiendo la comunicación y la interoperabilidad entre diferentes componentes de un sistema. Esta definición resalta el papel crucial de las APIs en la modularización y en la capacidad de sistemas heterogéneos para comunicarse de forma eficiente. En el contexto actual de ecosistemas digitales, las APIs no son solo herramientas técnicas, sino que representan la forma en que las organizaciones exponen sus funcionalidades y modelos de negocio, convirtiéndose en interfaces estratégicas para desarrolladores y para la creación de nuevas integraciones (Jin et al., 2018). La calidad del diseño de una API, por lo tanto, refleja directamente en la usabilidad, seguridad y sostenibilidad del sistema que la expone.

Diferentes paradigmas arquitectónicos de APIs coexisten, cada uno con sus particularidades en términos de interacción, acoplamiento y complejidad. El estilo arquitectónico Representational State Transfer (REST), propuesto por Fielding (2000), se ha consolidado como uno de los modelos más influyentes para el diseño de APIs web modernas. La principal característica de REST es la ausencia de estado (statelessness), donde cada solicitud del cliente al servidor contiene toda la información necesaria para ser comprendida, sin que el servidor necesite almacenar el contexto de la sesión del cliente entre las solicitudes. Este enfoque promueve la simplicidad, la escalabilidad y la separación de preocupaciones entre cliente y servidor, facilitando la evolución independiente de ambos lados de la comunicación. La adhesión a los principios RESTful, como el uso de recursos identificados por URLs y operaciones estandarizadas (métodos HTTP), es un indicador de madurez de una API, según el Modelo de Madurez de Richardson et al. (2007), que clasifica las APIs en niveles de adherencia a estos principios, desde llamadas a procedimientos remotos (Nivel 0) hasta la incorporación de hipermedia como motor del estado de la aplicación (HATEOAS, Nivel 3).

A diferencia de REST, otros paradigmas también se utilizan ampliamente. Las Llamadas a Procedimientos Remotos (RPC), por ejemplo, tienen como objetivo permitir la ejecución de funciones en un servidor remoto como si fueran llamadas locales (Birrel y Nelson, 1984). Si bien simplifican la invocación de métodos, las API RPC tienden a generar un mayor acoplamiento entre cliente y servidor, ya que la comunicación está orientada a acciones específicas, no a recursos. Otro protocolo notable es el Protocolo Simple de Acceso a Objetos (SOAP), un estándar basado en XML que define un formato estructurado para mensajes y reglas rigurosas de comunicación (W3C, 2007). SOAP se emplea frecuentemente en arquitecturas orientadas a servicios que demandan formalización de contratos, seguridad y alta fiabilidad, pero su complejidad puede ser un obstáculo en escenarios que exigen mayor agilidad. Finalmente, GraphQL, una especificación de API orientada a consultas, ofrece a los clientes la flexibilidad de definir exactamente qué datos desean obtener, reduciendo el volumen de datos transferidos y optimizando la eficiencia de la comunicación entre frontend y backend, operando generalmente a través de un único endpoint HTTP (Porcello y Banks, 2018). La elección del paradigma de API depende, por lo tanto, de los requisitos específicos del proyecto, considerando factores como flexibilidad, acoplamiento, rendimiento y facilidad de uso.

La perspectiva arquitectónica también es crucial en la clasificación y el diseño de APIs, influyendo directamente en la escalabilidad, el acoplamiento, el rendimiento y la mantenibilidad de las aplicaciones. La arquitectura monolítica, según lo descrito por Newman (2020), consiste en una única unidad de despliegue donde todas las funcionalidades se implementan y se ponen a disposición conjuntamente. Aunque puede ser más simple de desarrollar y desplegar inicialmente, un monolito de proceso único, donde todo el código se ejecuta como un único proceso, puede enfrentar desafíos de escalabilidad y robustez, incluso con múltiples instancias.

Fuente: Newman (2020)

Figura 1. Monolito de proceso único: todo el código se ejecuta en un único proceso

La Figura 1 ilustra la estructura básica de un monolito de proceso único, donde la aplicación y la base de datos están fuertemente acopladas. Una variación, el monolito modular, organiza el sistema en módulos lógicamente distintos, que pueden desarrollarse y mantenerse de forma independiente, pero aún se integran y despliegan como una única unidad (Newman, 2020).

Fuente: Newman (2020)

Figura 2. Monolito de proceso único: el código dentro del proceso se divide en módulos

La Figura 2 demuestra esta separación lógica dentro de un monolito, lo que puede mejorar la organización interna, pero no resuelve completamente los desafíos de implementación y escalabilidad inherentes a una única unidad. En contrapartida, la arquitectura de microservicios, según lo detallado por Newman (2021), consiste en servicios que pueden ser implementados de manera independiente, cada uno estructurado en torno a dominios de negocio específicos y comunicándose a través de APIs. Este enfoque evita el intercambio de bases de datos, siendo cada servicio responsable de su propio repositorio de datos, promoviendo mayor autonomía y resiliencia.

Fuente: Newman (2020)

Figura 3. Microservicios: los servicios se ejecutan de forma independiente

La Figura 3 representa la arquitectura de microservicios, destacando la independencia de los servicios y sus respectivas bases de datos, lo que confiere mayor flexibilidad y escalabilidad al sistema. La adopción de microservicios, aunque trae complejidad adicional en la gestión y orquestación, se justifica frecuentemente por la necesidad de sistemas altamente escalables, resilientes y con ciclos de desarrollo independientes.

La caracterización de la arquitectura del sistema en la nube heredado de la organización reveló un escenario común en sistemas de telemetría de equipos. Cada equipo fabricado por la empresa posee un módulo embebido que adquiere y transmite datos operativos, generando un volumen significativo de información. El backend existente, sin embargo, estaba estructurado como un monolito, donde todas las funcionalidades se implementaban y desplegaban como una única unidad. Este enfoque, aunque funcional para una etapa inicial, presentaba limitaciones significativas a medida que el volumen de datos y la demanda de interactividad en tiempo real crecían. La exposición de las funcionalidades a los frontends web y móvil se realizaba a través de una API basada en GraphQL, que, a pesar de ofrecer flexibilidad en las consultas, concentraba reglas de negocio, acceso a datos y capas de servicio en un único proceso, impactando la escalabilidad y la mantenibilidad.

Fuente: Resultados originales de la investigación

Figura 4. Principales componentes del sistema actual

Como se ilustra en la Figura 4, el sistema legado presentaba un acoplamiento directo entre la capa de servicios (Backend BFF / GraphQL) y la base de datos OLAP (Procesamiento Analítico en Línea). Esta base de datos, optimizada para soportar grandes volúmenes de datos y consultas analíticas complejas, resultaba ineficiente para escenarios que requerían respuestas transaccionales rápidas y baja latencia. El uso de una base de datos OLAP para satisfacer demandas en tiempo real provocaba lentitud en la renderización de información en la interfaz de usuario, comprometiendo la experiencia general. Esta limitación es un problema recurrente en arquitecturas monolíticas que intentan conciliar cargas de trabajo analíticas y transaccionales en el mismo repositorio de datos, evidenciando la necesidad de desacoplamiento y optimización para diferentes perfiles de acceso. La falta de una separación clara entre las responsabilidades de ingesta, procesamiento y consumo de datos contribuía a un sistema menos resiliente y más difícil de escalar horizontalmente, ya que cualquier cuello de botella en una parte del monolito afectaba el rendimiento de todo el sistema.

La propuesta de una nueva arquitectura en la nube buscó resolver las limitaciones identificadas en el sistema heredado, adoptando un enfoque híbrido que desacopla las cargas analíticas de las demandas de lectura en tiempo casi real. Esta reestructuración fue concebida para garantizar escalabilidad, mejorar el rendimiento y optimizar la organización de los datos.

Fuente: Resultados originales de la investigación

Figura 5. Diagrama C4 en vista de contenedor

La Figura 5, que presenta el diagrama C4 a nivel de contenedor de la nueva arquitectura, detalla la separación de responsabilidades. Los equipos en campo continúan enviando datos de telemetría a un Servicio de Ingesta de Datos vía WebSocket, que los persiste en la Base de Datos Analítica (OLAP). Esta etapa mantiene la compatibilidad con el sistema legado de recolección de datos. La innovación reside en la introducción de un Servicio de Consolidación de Datos, que procesa y materializa los datos brutos del OLAP, almacenándolos en una Base de Datos Transaccional (OLTP). Esta base de datos está optimizada para consultas de baja latencia, atendiendo a las necesidades de las aplicaciones de frontend. Los usuarios interactúan con el sistema a través de Aplicaciones Web y Móviles, que consumen una API REST proporcionada por el Backend para Frontend (BFF). Esta arquitectura promueve un desacoplamiento fundamental entre el procesamiento analítico y el consumo operacional, resultando en un mejor rendimiento para uso interactivo. La separación entre OLAP y OLTP, con un proceso de materialización de datos, es una práctica alineada con los principios de arquitecturas de datos modernas que buscan optimizar el acceso y el procesamiento para diferentes cargas de trabajo, como discutido por Fowler (2002) en patrones de arquitectura empresarial.

Fuente: Resultados originales de la investigación

Figura 6. Principales componentes de la solución propuesta

La Figura 6 complementa la visión del diagrama C4, representando los principales componentes de la solución propuesta en tres capas: presentación, servicios y datos. En la capa de presentación, los clientes web y móviles consumen datos a través de solicitudes a la API, mostrando dashboards e informes operativos. La capa de servicios está compuesta por el Servicio de Ingesta de Telemetría (recibiendo datos vía WebSocket), el Servicio de Materialización (consolidando datos del OLAP al OLTP) y la API REST Backend/BFF (abstraendo la complejidad de los datos y proporcionando respuestas optimizadas). La capa de datos utiliza la base de datos OLAP para datos brutos de telemetría y la base de datos OLTP para datos consolidados y de baja latencia, esenciales para la gestión y autenticación de usuarios. Este flujo de datos, dividido en procesos de escritura (recopilación, persistencia en OLAP, materialización en OLTP) y lectura (frontend accediendo a la API para datos consolidados del OLTP), garantiza mayor eficiencia y mejor experiencia del usuario. El enfoque de Backend for Frontend (BFF) es particularmente relevante aquí, ya que permite que la API se adapte a las necesidades específicas de cada tipo de cliente (web o móvil), reduciendo el acoplamiento y optimizando el consumo de información, una práctica recomendada por Newman (2020) para arquitecturas distribuidas. La compatibilidad con el sistema heredado, manteniendo el historial completo de los datos recopilados, es un beneficio adicional que asegura la integridad y la continuidad operativa.

La elaboración de la API REST fue un componente central de la investigación, centrándose en el diseño y desarrollo de la capa de servicios bajo el patrón Backend for Frontend (BFF). Esta capa actúa como un intermediario estratégico entre las aplicaciones cliente y los repositorios de datos, permitiendo que las respuestas se adapten a las necesidades específicas de cada tipo de frontend y a las reglas de negocio asociadas. La adopción del patrón BFF es una práctica reconocida por su capacidad para optimizar la experiencia del desarrollador de frontend, proporcionando una API que se adapta precisamente al consumo de una aplicación específica, en lugar de una API genérica que intenta satisfacer a múltiples clientes con diferentes requisitos. Esto minimiza la sobrecarga de datos y la complejidad en el lado del cliente, lo que resulta en aplicaciones más eficientes y con mejor rendimiento.

La estructuración de los endpoints de la API siguió una convención de rutas estandarizada, compuesta por un prefijo técnico (`/api`), la identificación del canal consumidor (`/web` o `/mobile`), un versionado explícito (`/v1`) y la segmentación por dominio funcional (`/auth` y `/users`).

Fuente: Resultados originales de la investigación

Figura 7. Descomposición del endpoint

La Figura 7 ilustra la descomposición del endpoint, evidenciando cómo cada segmento de la ruta contribuye a la organización y claridad de la API. Esta estrategia de diseño es crucial para reducir el acoplamiento entre los clientes y la API, ya que permite que diferentes versiones y canales de consumo coexistan y evolucionen independientemente. Además, mejora significativamente la organización de la documentación de la API, haciéndola más fácil de comprender y utilizar por los desarrolladores. La estandarización de los endpoints, como se demuestra en la Tabla 1, que presenta ejemplos detallados de endpoints de la API por canal consumidor, versión y dominio funcional, es una práctica fundamental para la gobernanza de APIs. Zimmermann et al. (2017) enfatizan que la gobernanza de APIs, incluyendo el versionamiento y la documentación automatizada (como Swagger/OpenAPI), es esencial para la sostenibilidad y usabilidad a largo plazo. La claridad y la previsibilidad de las rutas facilitan la integración de nuevos servicios y el mantenimiento de los existentes, garantizando que la API sea robusta y adaptable a las necesidades de los clientes y a la evolución del sistema. La Tabla 1, según se presenta en la sección de Materiales y Métodos, ejemplifica esta convención de rutas, mostrando cómo diferentes canales (web, móvil) y dominios funcionales (autenticación, usuarios, equipos) se organizan bajo un versionamiento explícito, lo cual es vital para gestionar la evolución de la API sin romper las integraciones existentes.

Las pruebas unitarias de las rutas de autenticación fueron cruciales para validar la seguridad y la funcionalidad de la API. La ejecución de los casos de prueba especificados en el Apéndice A, utilizando la herramienta `pytest`, permitió un análisis exhaustivo de escenarios funcionales y de seguridad.

Fuente: Resultados originales de la investigación

Figura 8. Resultado de la ejecución de las pruebas automatizadas de autenticación

La Figura 8 presenta los resultados de las pruebas unitarias de autenticación, mostrando que las 10 pruebas fueron aprobadas, con tiempos de ejecución eficientes. Estos resultados demuestran la robustez de la API para manejar diversas situaciones de autenticación.

En primer lugar, la API realiza correctamente la autenticación de usuarios válidos, devolviendo los datos esperados (CT01). Esto valida la funcionalidad básica de inicio de sesión, asegurando que los usuarios con credenciales correctas puedan acceder al sistema. La implicación práctica es la garantía de que el punto de entrada principal del sistema es funcional y confiable, permitiendo que los usuarios legítimos interactúen con la aplicación sin impedimentos. Este hallazgo es fundamental para la usabilidad y la adopción del sistema, ya que un proceso de autenticación fluido es la base para cualquier interacción segura.

En segundo lugar, la API rechaza adecuadamente las solicitudes inválidas o incompletas, con respuestas de error controladas y sin emisión de tokens (CT02 y CT03). Este comportamiento es vital para la seguridad, ya que impide intentos de acceso no autorizado y proporciona retroalimentación clara sobre fallos de autenticación. La práctica de devolver mensajes de error estandarizados e informativos, sin exponer detalles internos del sistema, es una buena práctica de seguridad que contribuye a la resiliencia de la API contra ataques de fuerza bruta o ingeniería social, según lo recomendado por Madden (2020).

Tercero, la API valida correctamente la obligatoriedad y consistencia de los datos de entrada, tratando las solicitudes incompletas o inválidas con respuestas de error apropiadas (CT04, CT05 y CT06). Esta validación rigurosa en la capa de entrada es una defensa primaria contra la inyección de datos maliciosos y garantiza la integridad de la información procesada. La conformidad con los tipos de datos y campos obligatorios es un pilar del diseño de APIs robustas, previniendo errores en el procesamiento y garantizando la estabilidad del sistema.

Cuarto, la API garantiza el control de acceso adecuado, impidiendo la autenticación de usuarios inactivos (CT07). Este es un requisito de seguridad crítico, ya que impide que cuentas desactivadas o suspendidas sean utilizadas para acceder al sistema. La gestión de estados de usuario, como activo/inactivo, es una funcionalidad esencial para la gobernanza de usuarios y para el mantenimiento de la seguridad del sistema a lo largo del tiempo, alineándose con las directrices de control de acceso en sistemas distribuidos.

Quinto, la API presenta conformidad con el contrato de la API, especialmente en lo que se refiere a la restricción de métodos HTTP permitidos (CT08). Esto significa que la API responde con el código de estado HTTP 405 (Method Not Allowed) para métodos no soportados en un determinado endpoint, garantizando que solo las operaciones esperadas sean aceptadas. La adherencia a los métodos HTTP (GET, POST, PUT, DELETE) y sus significados semánticos es un principio fundamental de REST, conforme Fielding (2000), que promueve la interoperabilidad y la previsibilidad del comportamiento de la API.

Sexto, la API mantiene consistencia en la estructura de las respuestas en escenarios de éxito, atendiendo a los requisitos definidos (CT09). La estandarización de la estructura de las respuestas facilita el consumo de la API por parte de los clientes, reduciendo la complejidad de integración y el tiempo de desarrollo. Una estructura de respuesta consistente es un indicativo de un diseño de API maduro y bien documentado, contribuyendo a la experiencia del desarrollador.

Finalmente, la API cumple con los criterios de seguridad, no exponiendo información sensible en el “payload” de respuesta (CT10). Este es un aspecto crucial de la seguridad de la información, previniendo la divulgación accidental de datos confidenciales que podrían ser explotados por atacantes. El filtrado de información sensible en las respuestas de la API es una práctica de seguridad esencial que protege la privacidad de los usuarios y la integridad del sistema, de acuerdo con las mejores prácticas de seguridad de APIs (Madden, 2020).

Las pruebas unitarias relacionadas con el flujo de autenticación basado en “tokens” también tuvieron éxito, validando los mecanismos de generación, validación, renovación y expiración de tokens de acceso, así como el manejo de usos indebidos.

Fuente: Resultados originales de la investigación

Figura 9. Resultado de la ejecución de las pruebas automatizadas de autenticación

La Figura 9 muestra que las 15 pruebas de flujo de tokens fueron aprobadas, incluida una prueba de rendimiento, lo que demuestra la robustez del sistema.

En primer lugar, el sistema genera correctamente tokens de acceso y de renovación para usuarios autenticados (CT11 y CT18). Esto es fundamental para la seguridad y la experiencia del usuario, ya que los tokens son la base para el acceso a recursos protegidos y para mantener la sesión activa sin la necesidad de reautenticación constante. La correcta generación de JSON Web Tokens (JWT) y tokens de refresh, conforme a las especificaciones de OAuth2, es un pilar de la seguridad moderna de APIs, garantizando que las credenciales de acceso sean efímeras y manejables.

En segundo lugar, la API permite el acceso a rutas protegidas solo mediante el uso de tokens válidos (CT12). Este control de acceso basado en tokens es esencial para proteger los recursos del sistema contra accesos no autorizados. La validación de cada token en cada solicitud a un recurso protegido asegura que solo usuarios autenticados y autorizados puedan interactuar con las funcionalidades sensibles de la aplicación, reforzando la seguridad de la API.

Tercero, la API rechaza adecuadamente tokens ausentes, inválidos, malformados o utilizados incorrectamente (CT13, CT14, CT15 y CT21). Este comportamiento es crucial para prevenir ataques de inyección de tokens o intentos de acceso con credenciales falsificadas. La robustez en la validación de tokens es una línea de defensa crítica, garantizando que solo tokens legítimos y bien formados sean aceptados, conforme a las directrices de seguridad de APIs (Madden, 2020).

Cuarto, la API garantiza la separación adecuada entre *access token* y *refresh token*, impidiendo su uso indebido (CT16 y CT22). Esta separación es una práctica de seguridad recomendada, donde el *access token* tiene un tiempo de vida corto y se usa para acceder a recursos, mientras que el *refresh token* tiene un tiempo de vida más largo y se usa solo para obtener nuevos *access tokens*. Esto minimiza el riesgo de compromiso de credenciales de larga duración, pues incluso si un *access token* es interceptado, su tiempo de validez limitado reduce la ventana de ataque.

Quinto, el sistema implementa correctamente el mecanismo de expiración de tokens, asegurando la invalidación tras el tiempo definido (CT23 y CT24). La expiración de tokens es un componente esencial de la seguridad, ya que limita el tiempo que un token comprometido puede ser usado. La validación de la expiración del token, tanto para *access tokens* como para *refresh tokens*, es fundamental para la gestión de sesiones seguras y para la mitigación de riesgos de seguridad.

Finalmente, la API presenta un rendimiento adecuado en las operaciones de autenticación y renovación de tokens (CT17). La eficiencia en el procesamiento de solicitudes de autenticación y renovación de tokens es vital para la experiencia del usuario y para la escalabilidad del sistema. Tiempos de respuesta rápidos en estas operaciones garantizan que la autenticación no se convierta en un cuello de botella de rendimiento, incluso bajo alta carga, contribuyendo a la sostenibilidad de la arquitectura.

Las pruebas unitarias de idempotencia de los métodos PUT y DELETE se realizaron para verificar la consistencia del estado de los recursos después de múltiples ejecuciones de la misma operación, así como la ausencia de efectos secundarios no deseados.

Fuente: Resultados originales de la investigación

Figura 10. Resultado de la ejecución de las pruebas automatizadas de idempotencia

La Figura 10 muestra que las 6 pruebas de idempotencia fueron aprobadas, con tiempos de ejecución rápidos.

En primer lugar, la API mantiene la consistencia del estado del recurso después de múltiples ejecuciones de peticiones PUT idénticas, caracterizando un comportamiento idempotente (CT25). La idempotencia es un principio fundamental del diseño RESTful, según Richardson et al. (2007), que garantiza que la ejecución repetida de una operación PUT no altere el estado del recurso más allá de la primera ejecución. Esto es crucial para la fiabilidad de sistemas distribuidos, donde las peticiones pueden ser reintentadas debido a fallos de red o temporales, sin causar inconsistencias de datos.

En segundo lugar, la API no genera duplicidad de datos cuando la misma operación PUT se ejecuta repetidamente (CT26). Este hallazgo refuerza la idempotencia del método PUT, asegurando que la actualización de un recurso no resulte en la creación de registros duplicados, lo que podría llevar a datos inconsistentes y problemas de integridad en la base de datos. La prevención de duplicidad es un beneficio directo de la correcta implementación de la idempotencia.

Tercero, la API garantiza que las solicitudes DELETE sucesivas mantienen el recurso en un estado de ausencia, sin revertir ni alterar el resultado esperado (CT27). De forma similar a PUT, el método DELETE debe ser idempotente, es decir, múltiples solicitudes para eliminar el mismo recurso deben resultar en el mismo estado final (recurso ausente), sin generar errores ni efectos secundarios. Esto es esencial para la robustez del sistema, permitiendo que las operaciones de eliminación se reintenten de forma segura.

Cuarto, la API maneja adecuadamente las llamadas repetidas de DELETE, no ocasionando errores internos en el servidor (CT28). La capacidad de manejar peticiones DELETE repetidas sin fallos internos demuestra la resiliencia de la API. Esto es particularmente importante en entornos distribuidos, donde la comunicación puede ser inestable y las peticiones pueden ser enviadas múltiples veces, y la API debe ser capaz de procesarlas sin comprometer su estabilidad.

Quinto, la API utiliza correctamente el método PUT para la actualización de recursos, sin efectos secundarios indebidos (CT29). Se valida la semántica correcta de PUT, que es la sustitución completa de un recurso, garantizando que las actualizaciones sean predecibles y no introduzcan efectos no intencionados en el sistema. Esto contribuye a la claridad y mantenibilidad de la API.

Finalmente, la API aplica correctamente el método DELETE para la eliminación de recursos, asegurando un comportamiento predecible y consistente (CT30). La validación del DELETE confirma que la eliminación de recursos ocurre de la manera esperada, sin dejar rastros ni estados inconsistentes. La predecibilidad del comportamiento de los métodos HTTP es un pilar para la construcción de APIs RESTful que son fáciles de entender e integrar.

Las pruebas unitarias de paginación se llevaron a cabo para validar el mecanismo de paginación de la ruta de listado de dispositivos, abarcando escenarios funcionales, validación de parámetros y consistencia de la respuesta de la API.

Fuente: Resultados originales de la investigación

Figura 11. Resultado de la ejecución de las pruebas automatizadas de paginación

La Figura 11 muestra que las 15 pruebas de paginación fueron aprobadas, con tiempos de ejecución consistentes.

En primer lugar, la API devuelve correctamente la primera página de resultados, respetando los parámetros informados (CT31). Esto valida la funcionalidad básica de paginación, garantizando que los usuarios puedan solicitar y recibir la primera parte de un conjunto de datos de forma predecible. La correcta implementación de la paginación es esencial para gestionar grandes volúmenes de datos, mejorando el rendimiento y la experiencia del usuario al evitar la transferencia de todos los datos de una sola vez.

En segundo lugar, la API permite la navegación entre páginas distintas sin repetición indebida de registros (CT32). La capacidad de navegar a páginas subsiguientes sin encontrar registros duplicados es crucial para la integridad de los datos presentados y para una experiencia de usuario fluida. Esto demuestra que el mecanismo de paginación está gestionando correctamente los offsets y límites de datos entre las solicitudes.

Tercero, la API respeta el límite de elementos definido por el parámetro `page_size` (CT33). La imposición del `page_size` garantiza que la cantidad de datos devueltos en cada solicitud sea controlada, optimizando el uso del ancho de banda y el tiempo de procesamiento en el cliente. Esta flexibilidad permite a los clientes ajustar la granularidad de la paginación según sus necesidades.

Cuarto, la API aplica correctamente la paginación por defecto cuando no se informan los parámetros (CT34). La definición de un comportamiento por defecto para la paginación, cuando los parámetros `page` y `page_size` no se proporcionan, es una buena práctica de diseño de API que mejora la usabilidad y la robustez, garantizando que la API siempre devuelva un conjunto de datos paginado, incluso en solicitudes simplificadas.

Quinto, la API maneja adecuadamente las solicitudes de páginas más allá del total disponible, devolviendo una respuesta controlada (CT35). En lugar de generar un error de servidor, la API debe devolver una respuesta que indique que la página solicitada está vacía o que no existe, lo cual es un comportamiento esperado y robusto. Esto evita fallos inesperados y proporciona una retroalimentación clara al cliente.

Sexto, la API rechaza valores inválidos para el parámetro `page`, como cero o negativos (CT36 y CT37). La validación rigurosa de los parámetros de entrada es fundamental para la seguridad y la estabilidad de la API, previniendo que valores maliciosos o incorrectos causen comportamientos inesperados o errores internos.

Séptimo, la API rechaza valores inválidos para el parámetro `page_size`, como cero o negativos (CT38 y CT39). Similarmente al parámetro `page`, la validación de `page_size` garantiza que solo se acepten valores positivos y razonables, evitando solicitudes que podrían sobrecargar el servidor o devolver resultados no deseados.

Octavo, la API limita correctamente el valor máximo de `page_size` o trata valores excesivos de forma controlada (CT40). La imposición de un límite máximo para el `page_size` es una medida de seguridad y rendimiento, previniendo que un cliente solicite un número excesivamente grande de elementos en una única petición, lo que podría llevar a cuellos de botella de rendimiento o ataques de denegación de servicio.

No, la API valida el tipo de los parámetros de paginación, rechazando valores no numéricos (CT41 y CT42). La validación de tipos de datos es una práctica de seguridad esencial, que garantiza que solo se acepten entradas numéricas para los parámetros `page` y `page_size`, protegiendo la API contra la inyección de código u otros ataques basados en tipos de datos incorrectos.

Décimo, la API mantiene la consistencia de la estructura de la respuesta paginada, según el contrato de la API (CT43). La estandarización de la estructura de la respuesta, incluyendo metadatos como `count`, `next` y `results`, facilita el consumo de la API por parte de los clientes y garantiza una experiencia de integración consistente.

Undécimo, la API garantiza la ausencia de superposición indebida de registros entre páginas consecutivas (CT44). La ausencia de superposición es crucial para la integridad de los datos y para garantizar que cada registro se presente una sola vez durante la navegación paginada.

Finalmente, la API aplica correctamente la paginación junto con filtros, manteniendo la coherencia de los resultados devueltos (CT45). La capacidad de combinar paginación con filtros es una funcionalidad avanzada que permite a los usuarios refinar sus búsquedas en grandes conjuntos de datos de forma eficiente, demostrando la flexibilidad y la robustez de la API.

En resumen, el diagnóstico de la arquitectura heredada evidenció limitaciones significativas en el uso exclusivo de OLAP para la atención en tiempo real, resultando en alta latencia y acoplamiento con el frontend. La adopción de una arquitectura híbrida, con la separación entre OLAP y OLTP y la implementación de un proceso de materialización de datos, demostró ser una solución eficaz. Este enfoque trajo ganancias sustanciales de rendimiento y organización, permitiendo consultas más rápidas y consistentes, lo que se alinea con las mejores prácticas de diseño de sistemas distribuidos (Fowler, 2002). La implementación de una API con el estándar Backend for Frontend (BFF), aliada a la definición de reglas de negocio y a una batería rigurosa de pruebas de validación, aumentó la confiabilidad y la adecuación de las respuestas a los clientes. Los resultados de las pruebas unitarias de autenticación, flujo de tokens, idempotencia y paginación confirmaron la conformidad de la API con los requisitos funcionales y de seguridad, así como su adherencia a las buenas prácticas de diseño RESTful, conforme Richardson et al. (2007) y Madden (2020).

Las implicaciones prácticas de estos resultados son vastas. La reducción de la latencia en las consultas mejora directamente la experiencia del usuario final, haciendo las aplicaciones más responsivas y eficientes. El desacoplamiento entre las cargas analíticas y operacionales aumenta la escalabilidad del sistema, permitiendo que soporte un volumen creciente de datos y usuarios sin comprometer el rendimiento. La estandarización del acceso a los datos vía API REST y la robustez de los mecanismos de autenticación y validación contribuyen a la seguridad y la mantenibilidad del sistema a largo plazo. La capacidad de filtrar y estructurar datos de forma más eficiente optimiza la utilización de los recursos computacionales y proporciona una base sólida para la toma de decisiones estratégicas.

Como mejoras futuras, la evolución hacia la materialización de datos en tiempo casi real, el uso de caché para optimizar el rendimiento de lectura, la implementación de mayor observabilidad (monitoreo y logs) y la maduración continua de las prácticas de ingeniería son aspectos cruciales para garantizar la escalabilidad y robustez continuas de la arquitectura. Adicionalmente, se vuelve esencial la ampliación de las pruebas de seguridad, incluyendo validaciones de autorización, protección contra vulnerabilidades conocidas (OWASP Top 10) y pruebas de carga enfocadas en escenarios críticos. Estas medidas adicionales asegurarán la integridad, confidencialidad y disponibilidad del sistema, consolidando la arquitectura propuesta como una solución tecnológica avanzada y sostenible.