Sistema de Telemetría RFID e Ingesta ServerlessDe la Restricción Física a la Arquitectura Resiliente
Los algoritmos de selección buscan coincidencias de texto. Los sistemas reales requieren principios de ingeniería.
El Origen: Cuando el código no es suficiente
Todo comenzó con un rechazo. Al postular a una posición técnica, mi perfil fue filtrado por un sistema ATS (Applicant Tracking System). El algoritmo no encontró las "palabras clave" exactas que buscaba, ignorando años de experiencia resolviendo problemas reales en la intersección del hardware y el software.
En lugar de simplemente "optimizar mi CV para el algoritmo", decidí construir algo que un filtro automático no pudiera ignorar: un sistema funcional, documentado y resiliente.
Los algoritmos de selección buscan coincidencias de texto. Los sistemas reales requieren principios de ingeniería.
Estructura del Sistema
En lugar de un diseño monolítico, organicé los componentes para que fueran independientes y tolerantes a fallos. A continuación, se muestra el flujo de datos desde la lectura del sensor en el Edge hasta la persistencia y visualización en la nube.
Diagrama de flujo de datos renderizado dinámicamente. Representa la arquitectura actual de la v1.0.
Desafíos de Integración y Soluciones Pragmáticas
Nota sobre este documento: Este Build Log es un documento vivo. A medida que el proyecto evoluciona hacia la v2.0 (MQTT + PostgreSQL), esta sección se extenderá para documentar los nuevos retos de migración, optimización de consultas y análisis de datos que surjan en el proceso.
Construir un sistema que conecta el mundo físico con la nube nunca es lineal. A continuación, detallo los obstáculos técnicos reales que surgieron durante el desarrollo de la v1.0 y las decisiones de ingeniería que tomé para resolverlos sin recurrir a la sobreingeniería:
1 · La ilusión de la conectividad constante
El Problema: En entornos reales, el WiFi falla. Un sistema que depende 100% de la nube para validar un acceso se vuelve inútil si hay una micro-caída de red.
La Solución: Implementé una validación local en el ESP32. El dispositivo mantiene un array en memoria de tarjetas autorizadas. Si el WiFi cae, el sistema sigue operando, registrando el evento localmente y reintentando la sincronización en segundo plano usando millis() para no bloquear el loop principal.
2 · Latencia y límites en la capa Serverless
El Problema: Las herramientas gratuitas como Google Apps Script tienen límites de ejecución y una latencia inicial (cold start) que puede hacer que un POST del ESP32 falle o se agote el tiempo de espera.
La Solución: Forcé al cliente HTTP del ESP32 a seguir redirecciones estrictas (HTTPC_STRICT_FOLLOW_REDIRECTS), ya que Apps Script redirige las peticiones. Además, implementé un sistema de reintentos exponenciales simples en el firmware y un manejo robusto de errores (try/catch) en el backend para garantizar que ningún dato se pierda silenciosamente.
3 · De los datos crudos a la información útil
El Problema: Una hoja de cálculo con cientos de filas de logs es inútil para un diagnóstico rápido o una auditoría técnica.
La Solución: Desarrollé un script en Python (generate_report.py con ReportLab) que consume el endpoint de datos, procesa los eventos y genera un reporte PDF estructurado con métricas de uptime y estado de red, sin necesidad de exponer credenciales directas.
Capacidades Arquitectónicas Validadas y Hoja de Ruta
Los entornos operativos reales no perdonan la sobreingeniería; requieren soluciones pragmáticas, tolerantes a fallos y fáciles de mantener. Este MVP cumple su objetivo actual, y los datos recopilados apuntan claramente hacia los objetivos de la siguiente iteración.
Eficiencia Operativa
$0.00 / mes
Infraestructura 100% serverless y gratuita en su capa actual, eliminando costos hundidos.
Resiliencia de Red
Validación Local
El sistema opera, registra y encola eventos incluso sin conexión a internet activa.
Hoja de Ruta (v2.0)
MQTT + PostgreSQL
Migración del protocolo HTTP a MQTT para reducir latencia y preparar el análisis de datos.