Gian Barboza. Gian Barboza — Ingeniero Backend Senior y Arquitecto de Software

Desarrollado con TypeScript, React y Next.js, con un backend separado en capas de dominio, aplicación e infraestructura. La persistencia en PostgreSQL utiliza Drizzle ORM sobre Neon. Auth.js gestiona Google OAuth y el acceso por correo electrónico mediante Resend; la autorización por titularidad controla la gestión de propiedades y el acceso al contacto de quien publica tiene límites de frecuencia.

El procesamiento de imágenes utiliza cargas firmadas a Cloudflare R2 con validación, versiones WebP generadas con Sharp y detección perceptual de duplicados. Los correos del ciclo de vida, el manejo de reintentos y la limpieza programada cubren las operaciones en segundo plano. Las pruebas unitarias y de integración con Vitest y las pruebas de navegador con Playwright incluyen flujos sin JavaScript, con controles de tipos, cobertura, compilación e integración en GitHub Actions.

Todos los proveedores viven detrás de un único contrato de pago. Cada integración adapta su propia API —distinta autenticación, distintos nombres de campos, distintas formas de error— a objetos de request y response normalizados, así el resto de la plataforma cobra, reembolsa o anula sin saber qué procesador hay del otro lado.

La selección y el comportamiento se desacoplan con patrones de diseño: un Factory resuelve qué integración construir, Strategy permite que cada proveedor tenga su propio comportamiento detrás del contrato común, los Adapters absorben las diferencias de cada API, un Builder arma los requests más complejos y un Repository mantiene la persistencia de transacciones fuera de la lógica de pago. El routing es configuración, no código —proveedor activo y cadena de prioridad por producto— con failover automático cuando el activo falla o rechaza. Cinco procesadores integrados de punta a punta (PayPal, Payeezy, DLocal, Stripe, Shift4) con 3DS, refunds, voids, Apple Pay, Google Pay y tokenización propia de tarjetas.

Separación del evaluador y las reglas. Un Factory construye cada regla, cada regla tiene una única responsabilidad, se autoregistra y recibe contexto ya normalizado — agregar un patrón significa agregar una clase, nunca editar el motor. El fraude de acceso corre como capa propia sobre device fingerprinting, manteniendo las señales de sesión (multicuentas, account takeover) fuera del camino transaccional.

También se prototipó una evaluación contextual con un LLM, imitando cómo decide un agente de soporte. Quedó en fase beta y no llegó a producción.

Rediseño hacia una arquitectura distribuida de 8 servidores en DigitalOcean, separando capas web, base de datos y dev para que ninguna carga pudiera ahogar a otra. HAProxy para balanceo HTTP, replicación MySQL master-slave para capacidad de lectura y standby, failover entre nodos, backups automatizados y runbooks de recovery.

El trade-off: el stack legacy no permitía aprovisionamiento automático, así que la topología se construyó a mano sobre Linux — más lento de levantar, pero eliminó el punto único de falla sin reescribir la aplicación primero. Liderando un equipo de 4 developers.