Contexto

Un sistema de estacionamientos inteligentes debe resolver más que una pantalla para reservar. La aplicación necesita consultar espacios disponibles, evitar conflictos de horario, registrar ocupación, sostener usuarios concurrentes y entregar información útil para administración.

En un entorno institucional el problema cambia durante el día: hay horas pico, usuarios con permisos distintos, zonas con reglas propias y eventos que alteran la disponibilidad. Si todo eso se concentra en un único servicio, cada cambio pequeño termina afectando funciones que no deberían tocarse.

Por eso la decisión principal fue separar dominios. Reservas, disponibilidad, autenticación y telemetría tienen ritmos de cambio distintos. Tratar cada uno como una capacidad independiente ayuda a mantener el backend claro y permite evolucionar una parte sin bloquear el resto del sistema.

Diseño backend

El API Gateway concentra la entrada de la aplicación móvil y permite ordenar rutas, seguridad, versionamiento y comunicación entre servicios. Detrás, cada servicio mantiene una responsabilidad clara: reservar, consultar disponibilidad, autenticar o registrar eventos de operación.

El servicio de reservas es el corazón transaccional. Debe validar horarios, estados de usuario, zona solicitada y disponibilidad antes de confirmar una operación. Su responsabilidad no es mostrar todo el estacionamiento, sino garantizar que una reserva sea coherente y trazable.

El servicio de disponibilidad trabaja con datos que cambian con frecuencia. Puede leer estados de zonas, espacios ocupados, ventanas de reserva y señales de ocupación. Cuando se requiere baja latencia, una capa temporal como Redis ayuda a responder más rápido sin reemplazar la fuente relacional.

PostgreSQL aporta consistencia para usuarios, zonas, espacios y reservas. El modelo relacional también facilita auditoría: saber quién reservó, cuándo, bajo qué regla y qué estado tenía el espacio en ese momento.

Consistencia y experiencia móvil

La app móvil debe recibir respuestas simples, rápidas y consistentes. El usuario no debería entender la arquitectura para saber si puede reservar. Por eso el backend debe traducir reglas complejas en estados claros: disponible, reservado, ocupado, no permitido o fuera de horario.

La consistencia no significa bloquear todo el sistema. Significa definir qué operaciones necesitan confirmación fuerte y cuáles pueden ser eventualmente actualizadas. Una reserva confirmada necesita más rigor que una métrica agregada para un panel administrativo.

  • Los límites de dominio reducen acoplamiento y facilitan mantener el backend.
  • Las validaciones deben vivir cerca de la regla de negocio, no solo en la interfaz móvil.
  • Los estados operativos deben tener nombres claros para evitar ambigüedad entre frontend, backend y administración.
  • La base de datos debe guardar suficiente historial para explicar una decisión del sistema.

Observabilidad desde el inicio

En microservicios, el fallo rara vez se entiende mirando un solo archivo de logs. Una reserva puede fallar por autenticación, por una regla de horario, por disponibilidad, por red o por base de datos. Si no hay trazabilidad, encontrar la causa toma demasiado tiempo.

Por eso conviene registrar eventos con identificadores de solicitud y mensajes orientados a operación. No basta con saber que algo falló; hay que saber en qué servicio ocurrió, con qué contexto y si el fallo fue técnico o de negocio.

  • Logs estructurados para seguir una reserva entre gateway, autenticación y dominio.
  • Métricas de latencia, errores, volumen de solicitudes y operaciones rechazadas por reglas de negocio.
  • Trazas para entender recorridos completos cuando la solicitud cruza varios servicios.

Aprendizaje principal

La arquitectura de un producto de movilidad no debe diseñarse solo para que compile. Debe diseñarse para operar con usuarios reales, cambios de reglas y datos que representan situaciones físicas. En ese punto, la ingeniería de software y el criterio operativo se encuentran.

UPS Parking es un buen caso porque obliga a combinar backend, mobile, datos, experiencia de usuario y operación institucional. El valor no está únicamente en reservar un espacio, sino en convertir esa interacción en un sistema mantenible y medible.