Caso de estudio
Plataforma de Marketplace en Producción
2026-presente Único desarrollador
Resumen
Diseñé y entregué una plataforma de marketplace en producción para descubrimiento público, flujos de gestión protegidos, ingesta de medios y trabajo operativo asíncrono. El sistema es una única aplicación renderizada en servidor y API, respaldada por persistencia relacional, caché, almacenamiento de objetos y una capa de workers aislada. Está en operación desde marzo de 2026.
Contexto
El producto necesitaba una experiencia de descubrimiento pública sin exponer los flujos sensibles de cuenta y operación. La aplicación tenía que aceptar medios generados por el usuario y ejecutar trabajo operativo recurrente que no debía competir con las peticiones interactivas. Los controles de abajo se describen por categoría; las configuraciones, los umbrales, los proveedores y los endpoints se mantienen privados.
Rol
Único desarrollador, responsable de la arquitectura, la implementación, la entrega y el sistema en producción que la rodea: el camino de petición, la integración de identidad, el pipeline de medios, la capa de workers y la observabilidad que los mantiene legibles.
Arquitectura
Un único proceso compone el frontend renderizado en servidor y la API: el mismo runtime sirve las páginas renderizadas y las rutas que hay detrás, lo que mantiene un solo despliegue, una sola postura de seguridad y un solo conjunto de clientes compartidos. Detrás se sitúan cuatro tipos de estado (una base de datos relacional, una caché, almacenamiento de objetos y una cola), y a cada uno se llega a través de servicios, nunca desde los controladores directamente.
Contexto del sistema / caso de estudio público
Un solo proceso SSR + API sobre estado compartido
El resto del caso recorre los caminos que importan: cómo se endurece una petición, cómo se establece una sesión, cómo se mantiene el trabajo en segundo plano fuera del camino de petición, cómo se ingieren los medios y cómo se mide el uso sin una escritura por vista.
Camino de petición y endurecimiento
Antes de que corra ningún handler, una petición cruza una secuencia fija de puertas compuesta en la raíz del servidor: seguridad de transporte y cabeceras de respuesta, identidad, controles de abuso y validación de esquema. Un handler solo llega a ver entradas que ya han sido autenticadas y parseadas, y devuelve una vista proyectada de los datos, no un registro en crudo.
Camino de petición / del borde al handler
Las puertas que cruza una petición antes de un handler
Autenticación y sesión
La identidad usa el flujo de código de autorización de OAuth 2.0 contra un proveedor OIDC externo. El redirect lleva un valor state que se comprueba a la vuelta con una comparación de tiempo constante; el token devuelto se verifica contra las claves de firma rotatorias del proveedor, con emisor, audiencia y expiración exigidos antes de confiar en él. La sesión vive luego en una cookie firmada y http-only, y el registro de usuario al que apunta se resuelve cache-first.
Autenticación / código de autorización OAuth 2.0
De una ruta guardada a una sesión resuelta
La resolución de sesión es donde la caché se gana su sitio: un token mapea a un id de usuario, y el id de usuario mapea a un registro de usuario cacheado, así que una petición autenticada rara vez toca la base de datos para saber quién pregunta. El logout y los cambios de cuenta vacían todos los tokens mapeados a ese usuario, de modo que una sesión obsoleta no puede sobrevivir al registro que hay detrás.
Trabajo asíncrono y aislamiento de la cola
El trabajo recurrente y diferido (notificaciones, procesamiento de contenido, el flush de telemetría y la limpieza de retención de datos) corre en un proceso worker separado contra una instancia de Redis dedicada, distinta del Redis que el camino de petición usa para caché y sesiones. Es la decisión operativa central de la plataforma.
Trabajo asíncrono / aislamiento del broker
El trabajo en segundo plano nunca comparte el Redis del camino de petición
Separar el broker de la caché significa que una ráfaga de trabajos en segundo plano no puede desalojar una caché caliente ni ahogar las búsquedas de sesión, y que el worker se puede reiniciar, escalar o caer sin arrastrar el manejo de peticiones. El coste es real: dos roles de Redis que operar, un segundo proceso que supervisar y trabajos que son consistentes con el tiempo, no de inmediato. Para trabajo que ningún usuario está esperando, es el intercambio correcto.
Ingesta de medios
Las subidas se transmiten en flujo, no se almacenan enteras en memoria, y cada archivo se autentica dentro del hook de subida antes de escribir un solo byte a disco. Un archivo cruza luego los chequeos de tipo y tamaño, se prepara en una ubicación temporal que aborta en el momento en que supera el límite de su ruta, y solo entonces se persiste en el almacenamiento de objetos. A la salida, las imágenes se sirven mediante URLs firmadas y con redimensionado en lectura, en lugar de exponer el objeto de origen.
Ingesta de medios / de la subida a la entrega
Cada archivo se autentica antes de escribir un solo byte
Telemetría sin una escritura por vista
El uso se mide en un camino caliente, así que no puede costar una escritura en base de datos por vista. Las vistas y eventos incrementan contadores en Redis y marcan las entidades tocadas en un dirty set; un worker vuelca en cada tick, lee el dirty set y funde los conteos acumulados en la base de datos en una sola transacción por lotes.
Telemetría / camino de escritura
Las vistas se acumulan en Redis y se vuelcan a Postgres por lotes
Dos detalles lo mantienen honesto bajo concurrencia. El flush decrementa solo lo que realmente escribió, así que las vistas que llegan a mitad del volcado se preservan para la siguiente pasada en vez de perderse, y una entidad sale del dirty set solo cuando su contador llega a cero. Las cifras de plataforma (visitantes únicos y demás) se registran de forma idempotente, de modo que un flush reintentado nunca puede contar doble. Un lock por visitante evita que un único espectador infle un contador.
Tradeoffs
El tema recurrente es aislamiento comprado con superficie operativa. Un broker dedicado y workers separados mantienen el trabajo asíncrono fuera del camino interactivo; una sesión cache-first mantiene la identidad barata pero añade un contrato de invalidación que respetar; un camino de telemetría con buffer mantiene el camino caliente rápido pero hace los conteos consistentes con el tiempo. Cada una de estas cosas añade algo que operar y supervisar, y cada una es deliberada.
Resultado
En operación desde marzo de 2026
Estado en producción
Fiabilidad y seguridad
Entre los controles implementados hay validación y saneamiento en servidor, OAuth/OIDC con validación de JWT/JWKS, guards de autorización, configuración segura de cookies, verificación de bots, ralentización progresiva selectiva, comprobaciones de medios, proyección de respuestas, workers de cola, logs estructurados, telemetría, caché y controles en CI. Son controles implementados, no una afirmación de cobertura, eficacia o certificación.
Qué mejoraría
Asumiría antes la propiedad de la capa de identidad, aunque eso aumente la superficie operativa que hay que mantener.
¿Necesitas un solo responsable técnico para la arquitectura de producto y la operación en producción? Hablemos de tu proyecto.