Forem: David De Los Santos Cuy Sánchez

Cómo uso Mermaid para comunicarme con producto, arquitecturar con devs y documentar todo al mismo tiempo

David De Los Santos Cuy Sánchez — Tue, 07 Apr 2026 05:04:09 +0000

Hay un momento en la carrera de casi todo desarrollador en el que te das cuenta de que el código ya no es el problema más difícil. El problema más difícil es explicarle a alguien de producto por qué el sistema funciona como funciona, o por qué un cambio que parece sencillo en realidad tiene diez implicaciones que no se ven a simple vista.

Durante mucho tiempo, mis herramientas para eso eran las mismas de siempre: una pizarra, una presentación armada de prisa, o en el mejor caso, un diagrama en draw.io que tardaba más en hacerse que en volverse obsoleto. El problema con esas herramientas no es que sean malas — es que viven desconectadas del código, del repositorio y de la realidad del sistema. En cuanto algo cambia, el diagrama miente.

Hasta que vi algo que cambió mi forma de trabajar.

La revelación: código que genera diagramas

Fue mi jefe quien me mostró por primera vez lo que Mermaid podía hacer. Había construido un script en Python que leía el esquema de la base de datos y generaba automáticamente un Entity Relationship Diagram en Mermaid. Ese diagrama vivía en el repositorio y se actualizaba solo con cada cambio mediante un flujo de GitHub Actions.

La primera vez que lo vi me quedé parado. No porque fuera magia — era código muy simple — sino porque conectaba dos mundos que yo siempre había tratado por separado: la documentación y el sistema real. Un diagrama que se genera desde la fuente de verdad no puede mentir. Es documentación viva.

Eso me abrió los ojos a algo más grande: si puedo generar un ERD automáticamente, ¿qué más puedo hacer con una herramienta que entiende texto y produce diagramas? ¿Qué pasa si la uso no solo para documentar para devs, sino para comunicar con producto?

El caso real: de 10 escenarios a 4 eventos

La respuesta llegó en un proyecto concreto. Estaba rediseñando un sistema de facturación para un equipo en otro país — lo cuento con más detalle en el post anterior sobre event-driven y facturación — y el punto de partida era una lista de más de 10 escenarios de negocio que el equipo de producto manejaba como casos independientes.

El equipo técnico los había modelado tal como producto los describía. El resultado era un sistema frágil, con lógica duplicada y casos borde que aparecían constantemente. Cuando empecé a analizar el dominio de verdad, encontré que todos esos escenarios eran variantes de solo 4 eventos de negocio reales.

El reto era convencer al equipo de producto de eso. No bastaba con decirlo — tenía que mostrarlo.

Usé dos tipos de diagramas Mermaid para hacerlo:

Timeline: para mostrar el patrón en el tiempo

El primer diagrama fue un timeline que mostraba cómo, a lo largo del ciclo de vida de una deuda, los 10+ escenarios que el equipo manejaba en realidad se repetían como instancias de los mismos 4 momentos. Ver los patrones distribuidos en el tiempo hizo inmediatamente visible algo que en texto era invisible: la complejidad era accidental, no esencial.

Sequence: para explicar cómo funcionarán los 4 eventos

El segundo diagrama fue un diagrama de secuencia que mostraba, de forma funcional y sin código, cómo cada uno de los 4 eventos fluiría a través del sistema: quién lo dispara, qué componentes se involucran, qué resultado produce.

sequenceDiagram
    actor Usuario
    participant Sistema
    participant EventBridge
    participant Facturacion as "Servicio de Facturación"

    Usuario->>Sistema: Realiza pago parcial
    Sistema->>Sistema: Valida monto y deuda
    Sistema-->>Usuario: Confirma recepción del pago
    Sistema->>EventBridge: Publica evento PagoParcialRegistrado
    EventBridge->>Facturacion: Entrega evento PagoParcialRegistrado
    Facturacion->>Facturacion: Actualiza saldo de la deuda
    Facturacion->>Facturacion: Genera registros contables
    Facturacion-->>EventBridge: Publica evento DeudaActualizada
    EventBridge-->>Sistema: Notifica actualización de deuda
    Sistema-->>Usuario: Muestra nuevo estado de la deuda

El equipo de producto entendió el modelo en esa misma reunión. No porque el diagrama fuera bonito — sino porque habló en su idioma: flujo, tiempo, actores, resultados. Sin terminología técnica innecesaria.

Los dos diagramas que más uso y cuándo

Después de ese proyecto, Mermaid se volvió una herramienta permanente en mi forma de trabajar. Estos son los dos tipos que más uso:

Sequence Diagram — mi favorito para comunicar con no técnicos

Es el diagrama que más valor me ha dado con áreas de negocio. Permite mostrar, a un nivel alto y sin código, cómo se comunican diferentes componentes entre sí: un proveedor externo con nuestros servicios, un usuario con el sistema, un evento disparando una cadena de reacciones.

Lo que hace especialmente útil al sequence es que funciona en dos niveles al mismo tiempo: para alguien de producto, muestra el flujo funcional de extremo a extremo. Para un desarrollador, es una guía de qué componentes debe tocar y en qué orden. Un solo diagrama, dos audiencias.

Flowchart — para flujos de proceso y decisiones

Cuando necesito mostrar un proceso con bifurcaciones, condiciones y caminos alternativos, el flowchart es la herramienta natural. Lo uso tanto para explicar procesos de negocio a producto como para documentar algoritmos y flujos de decisión para el equipo técnico.

flowchart TD
    A[Evento recibido] --> B{Tipo de evento}
    B -->|Adquisición| C[Procesar adquisición]
    B -->|Pago parcial| D[Aplicar pago parcial]
    B -->|Cierre de mes| E[Generar cierre de mes]
    B -->|Liquidación| F[Calcular liquidación]

    C --> G[Registrar en auditoría]
    D --> G[Registrar en auditoría]
    E --> G[Registrar en auditoría]
    F --> G[Registrar en auditoría]

    G --> H[Publicar eventos derivados]

Dónde viven los diagramas: la clave de la documentación viva

Una de las mayores ventajas de Mermaid es que no está atado a una sola herramienta. Dependiendo del contexto, uso:

GitHub Wikis: el diagrama vive junto al código, se versiona con git, y cualquier developer del equipo puede actualizarlo en el mismo PR donde modifica el sistema.
Confluence y Microsoft Loop: ambas tienen visualizadores nativos de Mermaid, útil cuando la documentación vive en herramientas corporativas.
draw.io: tiene un generador que toma código Mermaid y produce el diagrama visual, práctico para presentaciones o documentos formales.
Este mismo blog: integré un visor de Mermaid directamente, así que los diagramas que estás viendo en este post son código Mermaid renderizado en tiempo real. Hashnode también lo soporta de forma nativa. dev.to, por ahora, no tiene ese visor — ahí los bloques aparecen como código plano.

La versatilidad es real: el mismo bloque de texto produce el diagrama en la mayoría de esos contextos. No hay que rehacerlo, exportarlo ni mantener dos versiones.

Por qué Mermaid y no otra cosa

Es código, entonces es versionable. El diagrama vive en el repositorio, cambia con un commit, y su historial de cambios es el historial del sistema. Cuando alguien pregunta "¿cómo funcionaba esto hace seis meses?", el diagrama tiene la respuesta.

Es automatizable. Como el ERD que me mostró mi jefe: puedes generar diagramas desde una fuente de verdad y actualizarlos automáticamente con GitHub Actions o cualquier pipeline de CI. Documentación que se mantiene sola.

Es compatible con IA. Hoy en día, generar o modificar un diagrama Mermaid con un LLM es trivial. Describes el flujo en lenguaje natural y obtienes el código del diagrama. La barrera de entrada desapareció.

Cómo empezar mañana

Si nunca has usado Mermaid, abre mermaid.live y escribe tu primer diagrama de secuencia. La sintaxis es legible — en 15 minutos tienes algo funcional.

Si ya lo conoces pero no lo estás usando con negocio, el próximo proyecto donde tengas que explicar un flujo a alguien no técnico es tu oportunidad. Antes de armar la presentación, prueba hacer el sequence diagram primero. Te vas a sorprender de cuánto más rápido llega el entendimiento.

Y si quieres llevar la documentación al siguiente nivel, agrega un paso a tu pipeline de CI que genere o valide tus diagramas desde el código. El mismo principio del ERD automático aplica a cualquier artefacto del sistema que puedas describir en texto estructurado.

Mermaid no es solo una herramienta de diagramas. Es la forma en que los diagramas dejan de ser documentación que envejece y se convierten en parte viva del sistema.

¿Usas Mermaid en tu día a día? ¿Tienes algún caso de uso que no mencioné aquí? Me encantaría leerlo en los comentarios.

Cuando el negocio no es el tuyo: cómo entender el dominio para rediseñar un sistema de facturación con event-driven

David De Los Santos Cuy Sánchez — Fri, 03 Apr 2026 02:54:37 +0000

Llegué a ese proyecto sin saber exactamente en qué me estaba metiendo.

El sistema tenía problemas de facturación: cargos que no se aplicaban, cargos duplicados, y nadie con certeza absoluta de cuándo debía procesarse uno. El equipo de producto tenía documentados más de 10 escenarios. Y yo, que venía de otro país, tenía que entender primero cómo funcionaba ese negocio con sus propias reglas, sus propios términos y su propia lógica.

Esa combinación — un sistema roto, un dominio que no era el mío y presión por resolverlo — es exactamente el tipo de situación donde es tentador ir directo al código. Por suerte, no lo hice.

El síntoma: una lista interminable de “cuándo facturar”

Cuando llegué al sistema, lo primero que vi fue la lista de escenarios que el equipo manejaba:

El cliente tiene una deuda activa sin pago
El cliente tiene una deuda activa con pago
El cliente tiene una deuda activa con pago y es fin de mes
El cliente tiene una deuda activa sin pago y es fin de mes
... y múltiples combinaciones de los anteriores

Antes — lógica basada en combinaciones de estados:

flowchart TD
    A[Sistema detecta cambio] --> B{¿Deuda activa?}
    B -->|Sí, sin pago| C{¿Es fin de mes?}
    B -->|Sí, con pago| D{¿Es fin de mes?}
    B -->|No| E[No facturar]
    C -->|Sí| F[Facturar: sin pago + fin de mes]
    C -->|No| G[Facturar: sin pago]
    D -->|Sí| H[Facturar: con pago + fin de mes]
    D -->|No| I[Facturar: con pago]
    F --> J[...y más combinaciones]
    G --> J
    H --> J
    I --> J
    J --> K[❌ Duplicados / cargos perdidos]

El equipo técnico los había modelado tal como el equipo de producto los había descrito. Y el equipo de producto los había descrito tal como los había visto ocurrir en el sistema. El problema es que eso no es el negocio — son los síntomas del negocio.

Hay una diferencia importante entre “esto es lo que pasa en el sistema” y “esto es lo que significa para el cliente”. Cuando modelas los primeros, terminas con lógica frágil que se rompe ante cualquier caso borde. Cuando modelas los segundos, encuentras los patrones reales.

Lo que teníamos era un sistema que reaccionaba a estados del sistema. Lo que necesitábamos era un sistema que reaccionara a eventos del negocio.

El proceso: aprender el dominio antes de tocar el código

Tomé la decisión de no proponer ninguna solución técnica hasta entender cuándo debía procesarse un cargo de verdad. Esto implicó sesiones con el equipo de producto — no para que me explicaran los escenarios del sistema, sino para que me explicaran el negocio: ¿qué cambia en la vida del cliente para que se genere una obligación?

Esa distinción cambió completamente la conversación. Empezamos a hablar en términos del ciclo de vida de una deuda, no de combinaciones de estados. Y cuando haces eso, la lista interminable de escenarios empieza a colapsar. Muchos de ellos eran variantes del mismo momento de negocio, disparados desde diferentes partes del código por razones históricas, no por razones lógicas.

Al final, todo el ruido se redujo a 4 eventos de negocio reales:

Adquisición del préstamo — el cliente adquiere una deuda
Pago parcial del usuario — el cliente realiza un abono
Fin de mes con pagos — cierre del periodo, se consolidan los movimientos
Liquidación de la deuda — el cliente salda completamente

Cualquier escenario de la lista original era consecuencia de uno de estos cuatro. No había un quinto evento. Solo había complejidad accidental acumulada con el tiempo.

La solución técnica: AWS EventBridge como bus central

Con el modelo de negocio claro, la implementación se volvió relativamente directa. Usamos AWS EventBridge como bus de eventos central.

Después — 4 eventos de negocio claros:

flowchart LR
    A[🏦 Adquisición del préstamo] --> E
    B[💸 Pago parcial del usuario] --> E
    C[📅 Fin de mes con pagos] --> E
    D[✅ Liquidación de la deuda] --> E
    E([EventBridge]) --> F[Servicio de Facturación]
    F --> G[✓ Cargo generado correctamente]

Cada dominio publica eventos de negocio cuando algo relevante ocurre. El servicio de facturación escucha únicamente los 4 eventos que importan y ejecuta la lógica correspondiente.

Una ventaja importante que ya venía del diseño del sistema: cada evento traía un identificador único derivado de los movimientos contables. Esto eliminó de raíz el problema de duplicados sin necesidad de lógica adicional — la trazabilidad ya estaba en el dato.

Dead letter queue para fallos. Los eventos que no se procesan correctamente van a una DLQ para revisión, en lugar de perderse silenciosamente como pasaba antes.

Logs de auditoría por evento. Cada evento procesado deja un registro con su ID, timestamp y resultado. Por primera vez, el equipo tenía visibilidad completa del ciclo de facturación.

El resultado

El cambio fue inmediato. Los cargos duplicados desaparecieron. Los cargos perdidos también. El equipo de producto pasó de manejar excepciones manualmente cada semana a tener un sistema que, cuando falla, falla de forma visible y recuperable.

Pero lo que más me quedó no fue el resultado técnico. Fue lo que aprendí sobre cómo enfrentar sistemas en dominios que no conoces.

La lección de arquitectura

Hay un concepto útil para este tipo de situaciones: la distinción entre complejidad esencial y complejidad accidental.

La complejidad esencial viene del negocio. Si la facturación de préstamos es complicada, es porque el negocio tiene reglas complicadas. No puedes eliminarla, solo modelarla bien.

La complejidad accidental es la que nosotros mismos creamos: código que creció sin diseño, escenarios modelados como síntomas, lógica duplicada por urgencia. Esta sí puedes eliminarla — pero solo si primero entiendes cuál es cuál.

Los 10+ escenarios que teníamos eran mayormente complejidad accidental. Los 4 eventos que encontramos eran la complejidad esencial del negocio. El trabajo fue separar una de la otra.

Como gente de tech, a veces caemos en la trampa de modelar lo que vemos en lugar de modelar lo que es. Vemos muchos casos, muchos estados, muchas combinaciones — y construimos un sistema para cada uno. Pero casi siempre, detrás de esa superficie hay un modelo más simple esperando ser descubierto.

La próxima vez que enfrentes un sistema “complejo”, antes de buscar la solución técnica, hazte esta pregunta: ¿estoy mirando el negocio o estoy mirando los síntomas del negocio?

¿Te ha tocado simplificar un dominio que parecía irreduciblemente complejo? Me encantaría leer cómo lo abordaste en los comentarios.

El algoritmo que se moría en CDMX: de O(10 ) a una consulta SQL

David De Los Santos Cuy Sánchez — Tue, 31 Mar 2026 03:28:43 +0000

El algoritmo que se moría en CDMX: cómo pasé de O(10⁷) a una consulta en base de datos

Hace algunos años trabajé en un proyecto de marketing por teléfono. El objetivo era generar listas de números telefónicos válidos para hacer campañas de llamadas en distintas ciudades de México. Si en algún momento recibiste una de esas llamadas… lo siento. No fue personal.

El punto técnico del asunto era este: necesitábamos generar números de teléfono que fueran válidos según la regulación del IFT (Instituto Federal de Telecomunicaciones). Y para eso, construimos un algoritmo. Uno que funcionaba. Pero que a cierta escala, simplemente se moría.

Cómo funcionan los teléfonos en México (lo mínimo necesario)

En México, todos los números telefónicos tienen 10 dígitos. Lo interesante es que los primeros 2, 3 o 4 dígitos están asignados a una localidad y estado específicos según la numeración publicada por el IFT. Esto significa que si sabes en qué ciudad quieres operar, ya conoces una parte del número desde el inicio.

Pero el IFT no solo define los prefijos: también establece restricciones sobre qué combinaciones de dígitos son válidas. No todos los sufijos son permitidos. Hay reglas.

Así que el problema real era: dado un prefijo de ciudad, generar todas las combinaciones válidas de los dígitos restantes (entre 6 y 8 dígitos, dependiendo del prefijo), respetando las restricciones del regulador.

La primera versión: el infierno de los `for`

La implementación inicial fue lo más natural que se me ocurrió en ese momento: ciclos for anidados.

La lógica era directa: iterar sobre cada posición de dígito, generar todas las combinaciones posibles, y dentro de cada iteración aplicar los if con las reglas del IFT para filtrar las combinaciones inválidas.

En el peor caso —ciudades con prefijo de 3 dígitos, donde quedan 7 dígitos libres— la complejidad llegaba a O(10⁷), es decir, hasta 10 millones de iteraciones solo para generar las combinaciones, antes siquiera de aplicar los filtros.

Para ciudades pequeñas, funcionaba. Tardaba un rato, pero terminaba.

Para ciudades como CDMX o Monterrey, el proceso tardaba horas. Literalmente. Y en aquella época yo no tenía experiencia con servidores ni procesamiento distribuido, así que el script corría en local, peleando contra los límites de memoria y CPU de mi equipo.

El algoritmo era correcto. El problema era el enfoque.

El insight clave: el problema no era el algoritmo, era la herramienta

Llegó un momento en que me puse a pensar diferente. El cuello de botella no era la lógica de negocio —las reglas del IFT eran las mismas sin importar cómo las implementara—. El problema era que estaba usando un proceso iterativo para resolver algo que en realidad era un problema de combinación de conjuntos de datos.

Y los motores de bases de datos llevan décadas siendo increíblemente buenos para exactamente eso.

El cambio de mentalidad fue este:

En lugar de generar las combinaciones con código, ¿qué tal si modelo las reglas como datos y dejo que la base de datos haga el cruce?

La solución: tablas temporales + JOINs + bulk insert

El nuevo enfoque funcionó así:

1. Las reglas del IFT se convirtieron en tablas

En lugar de tener las restricciones codificadas en if dentro de los ciclos, las traduje a tablas (muchas veces temporales) en la base de datos. Cada tabla representaba los valores válidos para una posición de dígito, condicionados al estado y localidad seleccionados.


sql

-- Ejemplo simplificado

CREATE TEMPORARY TABLE digitos_validos_pos1 AS

SELECT valor

FROM reglas_ift

WHERE estado = 'CDMX'

AND posicion = 1;

Cómo conecté Slack, Notion, Google Calendar y Sanity con Claude como orquestador para automatizar mi blog

David De Los Santos Cuy Sánchez — Wed, 25 Mar 2026 15:53:20 +0000

Tenía el problema clásico de cualquier persona que quiere construir una marca personal técnica: las ideas llegaban en el momento menos oportuno. En medio de una reunión, en la ducha, en el camino al trabajo. Las anotaba en cualquier lado, y la mayoría moría ahí.

Cuando sí tenía tiempo para escribir, el proceso era tan manual que el costo de activación era altísimo: abrir Notion, crear la entrada, pensar el outline, escribir el post, buscar una imagen, publicar en Sanity, redactar el post de LinkedIn… Para cuando llegaba al final, ya no quería volver a hacerlo.

Entonces decidí resolver el problema como lo haría cualquier arquitecto de software: construyendo un sistema.

El problema que quería resolver

No era falta de ideas. Era fricción.

Cada paso del proceso de publicación vivía en una herramienta diferente, sin conexión entre ellas. Y cada vez que tenía que pasar de una a otra manualmente, había una probabilidad alta de que el post nunca viera la luz.

Lo que necesitaba era un pipeline de contenido que funcionara como funciona un pipeline de CI/CD: automatizado, confiable, y que me dejara enfocarme solo en lo que no se puede automatizar — la experiencia real y el criterio técnico.

La arquitectura del sistema

El flujo completo quedó así:

[0] IDEA          →  Slack (#mi-blog-para-mi-marca-personal)
[1] CAPTURA       →  Notion (Inspiration & Ideas)
[2] PRIORIZACIÓN  →  Notion + Google Calendar
[3] OUTLINE       →  Notion (Blog Posts)
[4] REDACCIÓN     →  Skill: blog-tech-writer
[5] IMAGEN        →  Skill: blog-image-prompter → Gemini
[6] REVISIÓN      →  Notion (Editing → Ready to Publish)
[7] PUBLICACIÓN   →  Sanity CMS
[8] DISTRIBUCIÓN  →  Skill: blog-linkedin-advisor

El orquestador de todo esto es Claude, ejecutado desde Cowork — una herramienta de Anthropic que permite a Claude tomar acciones reales en aplicaciones conectadas vía MCP (Model Context Protocol).

Los MCPs conectados son: Slack, Notion, Google Calendar, y Sanity. Cada uno expone herramientas que Claude puede invocar directamente, sin intermediarios.

Cómo funciona en la práctica

Paso 1: La idea nace en Slack

El canal #mi-blog-para-mi-marca-personal es mi buzón de ideas. Lo uso desde el móvil, sin pensar demasiado. Un mensaje, una frase, un contexto.

Lo que antes perdía porque no tenía dónde anotarlo ahora queda registrado con timestamp, searchable, y accesible para Claude.

Paso 2: Claude procesa y registra en Notion

Con un solo prompt, Claude revisa el canal de Slack, extrae las ideas nuevas y las registra automáticamente en la base de datos Inspiration & Ideas de Notion con el status New, la fuente, y las notas de contexto.

Incluso responde en el hilo de Slack confirmando el registro. No tengo que hacer nada más que lanzar el prompt.

Paso 3: Priorización semanal

Cada lunes, Claude revisa las ideas pendientes en Notion y mi disponibilidad en Google Calendar. Me propone qué escribir esa semana, con justificación basada en mi audiencia y perfil, y agenda dos eventos: uno para escribir y otro para publicar.

Esto resolvió uno de los problemas más sutiles: el de la parálisis por elección. Tener alguien que te diga "esta semana escribe esto y por esta razón" cambia completamente la dinámica.

Paso 4: Redacción con el skill blog-tech-writer

Este es el paso donde más valor genera el sistema. El skill blog-tech-writer está entrenado con mi perfil, mi tono, y mi audiencia. No produce posts genéricos de internet — produce posts que suenan a mí, desde mi experiencia real.

Cuando le digo "redacta el post del outline en Notion", Claude lee el outline, lo combina con el contexto de mi perfil y genera un draft completo en Markdown. El draft va directo a Notion con el status Drafting.

Paso 5: Imagen y distribución

El skill blog-image-prompter genera un prompt optimizado para Gemini — ahí sí hay un paso manual porque necesito generar la imagen y subirla. Pero al menos el prompt está listo y guardado en Notion.

El skill blog-linkedin-advisor genera dos variantes del post de LinkedIn: una más técnica y una más narrativa. Las guarda en Notion para que yo elija cuál usar.

Paso 6: Publicación en Sanity

Cuando el post está listo y aprobado, Claude lo toma de Notion y lo sube a Sanity como draft. Yo reviso una última vez en el Studio y publico.

Lo que aprendí construyendo esto

Los sistemas de contenido son igual de importantes que los sistemas de software. Un pipeline de publicación sin automatización tiene los mismos problemas que un proceso de deployment manual: es lento, propenso a errores, y depende de que alguien tenga energía y tiempo al mismo tiempo.

El MCP es el cambio de paradigma que estaba esperando. No es solo que Claude pueda responder preguntas — es que Claude puede tomar acciones reales en tus herramientas. La diferencia entre un asistente que te dice qué hacer y uno que lo hace contigo es enorme.

Las skills son el activo más valioso del sistema. El skill blog-tech-writer no es magia — es contexto bien documentado sobre cómo escribo, a quién le escribo y qué quiero lograr. Cualquiera puede construir el suyo.

La consistencia gana a la perfección. Este sistema no genera el mejor post posible. Genera el post que de otra forma no existiría. Y eso vale más.

¿Vale la pena el setup inicial?

El setup tomó tiempo. Diseñar el flujo, documentar las skills, conectar los MCPs, probar cada etapa. Pero fue una inversión de arquitectura, no de operación.

Hoy el costo de publicar un post es una fracción de lo que era antes. Y lo más importante: el costo de no publicar subió — porque el sistema está ahí, esperando ideas.

Si estás construyendo una marca personal técnica y tienes el mismo problema que yo tenía, la pregunta no es si deberías automatizar tu flujo de contenido. La pregunta es cuánto más vas a esperar para hacerlo.

¿Tienes preguntas sobre cómo armar algo similar? Cuéntame en los comentarios o encuéntrame en LinkedIn.

Cómo rediseñamos un backend completo sin detener la operación

David De Los Santos Cuy Sánchez — Fri, 20 Mar 2026 15:00:25 +0000

El sistema llevaba cinco días en producción cuando llegué

No hubo inducción. No hubo documentación. Hubo reuniones de crisis a puerta cerrada y un silencio incómodo cada vez que preguntaba qué estaba pasando.

Mi rol formal era líder de automatización de QA. Pero conforme me fui involucrando en el contexto, quedó claro que el problema no era de calidad de pruebas. Era de arquitectura.

El motor principal de base de datos era DynamoDB, una base de datos NoSQL de AWS diseñada para patrones de acceso por clave, alta escala y lecturas/escrituras predecibles. Nada de eso se había aprovechado. Había sido usada como si fuera una base de datos relacional: con relaciones entre entidades, consultas complejas, joins implícitos en código de aplicación y una cantidad notable de lógica que dependía de estructuras que DynamoDB simplemente no garantiza.

El sistema era técnicamente funcional. Pero estaba construido sobre una base que haría que cada nueva funcionalidad costara el doble de esfuerzo del necesario.

Por qué es difícil cuando el sistema ya está en producción

Aquí está el problema real: no era un prototipo. Había usuarios reales. Había operaciones financieras activas. No había opción de "apagar y rehacer".

Esto es lo que hace diferente rediseñar un backend en producción versus construir uno nuevo:

No puedes romper lo que ya funciona. Aunque lo que funciona sea frágil, es lo que está sosteniendo la operación. Cada cambio tiene un costo real, no solo técnico.

El conocimiento está disperso. El equipo original tomó decisiones bajo presión. Parte de la lógica de negocio estaba en la cabeza de personas que ya no estaban disponibles, o directamente en el comportamiento del sistema que nadie había documentado.

El tiempo no se detiene. Mientras el equipo de refactorización trabaja en el backend nuevo, los usuarios del sistema actual siguen operando. Cualquier inconsistencia entre ambos mundos se convierte en un problema de datos.

La decisión que se tomó desde dirección fue sensata en ese contexto: dividir en dos equipos. Uno mantendría el sistema actual operando. El otro construiría el backend nuevo desde cero. La empresa además hizo un freeze de nuevas altas para reducir la presión de crecimiento mientras se estabilizaba.

Me asignaron al equipo de soporte.

Lo que aprendí estando del lado que nadie quiere estar

Mantener un sistema que sabes que va a ser reemplazado es una experiencia particular. No es glamoroso. No es lo que uno imagina cuando piensa en "trabajo técnico interesante".

Pero fue donde aprendí las reglas de negocio reales.

Cada bug que se destraba en soporte es una historia: por qué ese flujo existe, qué caso borde representa, qué decisión de negocio hay detrás. Con el tiempo, esa acumulación de contexto se vuelve un activo valioso, aunque en el momento no se sienta así.

Cuando finalmente pude moverme al equipo de refactorización, mi jefe fue directo:

"Te tocará tomar el toro por los cuernos."

Y sí. Así fue.

La migración de DynamoDB a PostgreSQL

Lo más común en la industria es lo contrario: empresas que migran de bases de datos relacionales a soluciones NoSQL para escalar. Hacerlo al revés tiene sus propios retos.

El modelo mental es diferente. DynamoDB te obliga a pensar en patrones de acceso primero. PostgreSQL te da flexibilidad para consultar desde múltiples ángulos. Migrar el modelo de datos implicó entender qué estructura tenía el dato en Dynamo, cómo se estaba usando en realidad, y qué forma debería tener en un esquema relacional bien diseñado.

Los datos no se migran solos. Hubo que escribir scripts de transformación, validar integridad, manejar datos inconsistentes que el sistema anterior había aceptado sin queja. Los bordes del modelo de DynamoDB habían permitido guardar cosas que PostgreSQL rechazaría con una restricción de llave foránea o una constraint de unicidad.

El release fue nocturno. Obviamente. Los releases importantes siempre son nocturnos. Hubo problemas. Siempre hay problemas. Migramos datos, apagamos servidores, movimos el switch, prendimos el nuevo sistema, y empezamos a leer logs con la misma intensidad con la que se lee un mensaje importante que tardó en llegar.

Funcionó. No de forma perfecta en las primeras horas, pero funcionó.

Lecciones que me quedaron

1. El contexto de negocio no está en el código. Está en los tickets de soporte, en las conversaciones de emergencia, en los edge cases que nadie documentó. Si tienes la oportunidad de estar cerca de la operación antes de rediseñar algo, no la desperdicies.

2. DynamoDB no es una base de datos relacional. Parece obvio. No siempre lo es cuando hay presión de tiempo y el equipo no tiene experiencia previa con la tecnología. Antes de elegir una base de datos, la pregunta correcta no es "¿qué bases de datos conocemos?" sino "¿qué patrones de acceso tenemos?".

3. Dividir el equipo fue la decisión correcta. Intentar mantener la operación y construir el nuevo sistema con el mismo equipo y al mismo tiempo es una receta para hacer las dos cosas mal. La separación de responsabilidades aplica también a nivel organizacional.

4. La estabilidad no siempre se ve bien desde adentro. Hubo un momento donde el sistema estaba "estable". No era bonito. No era lo que queríamos. Pero estaba sosteniendo la operación. A veces eso es suficiente para avanzar al siguiente paso.

5. Los releases nocturnos tienen sus propios patrones de falla. Cansancio, presión, menor visibilidad del impacto real. Tener runbooks claros, criterios de rollback definidos de antemano y una comunicación fluida en el equipo vale más que cualquier optimismo previo al deploy.

Conclusión

Rediseñar un backend en producción no es solo un ejercicio técnico. Es una operación que requiere contexto de negocio, coordinación de equipos, gestión de datos sucios y tolerancia a la ambigüedad.

La tecnología en sí, migrar de DynamoDB a PostgreSQL en este caso, fue la parte más predecible del proceso. Lo que realmente definió el resultado fue haber entendido el sistema antes de cambiarlo.

La arquitectura no empieza en el diseño. Empieza en entender qué problema está resolviendo el sistema actual, aunque ese sistema esté mal construido.

Vibe coding funciona. Pero primero necesitas saber diseño de software

David De Los Santos Cuy Sánchez — Fri, 20 Mar 2026 03:25:20 +0000

Tengo un blog. Escribo en Sanity porque me gusta la experiencia, tengo control total del contenido y se integra perfectamente con mi portafolio. El problema es que también quiero publicar en Dev.to y Hashnode — donde vive buena parte de la comunidad técnica.

Durante un tiempo lo hacía a mano. Terminaba el post en Sanity, copiaba el markdown, abría Dev.to, pegaba, ajustaba los tags, publicaba. Repetía el proceso en Hashnode. Si después corregía algo en Sanity, volvía a hacer todo de nuevo.

No tardé mucho en decidir que eso no era sostenible.

La idea: Sanity como hub de publicación

Lo que quería era simple: escribir una sola vez en Sanity y que el resto pasara solo. Cuando publico un post, un webhook dispara una Lambda en AWS que toma el contenido y lo manda a todas las plataformas configuradas.

El flujo completo es este:

Publico un post en Sanity CMS
Sanity dispara un webhook POST /publish hacia API Gateway
La Lambda valida la firma HMAC-SHA256 del webhook
Consulta la GROQ API de Sanity para obtener el post completo
Publica en cada plataforma configurada (Dev.to, Hashnode...)
Devuelve 200 si todo salió bien, 207 si hubo éxitos parciales, 502 si todo falló

Sencillo en papel. Pero la parte interesante está en cómo está estructurado el código.

Por qué no usé un if-else gigante

Mi primer instinto al implementar esto fue escribir algo como:

if platform == "devto":
    # publicar en dev.to
elif platform == "hashnode":
    # publicar en hashnode
elif platform == "medium":
    # publicar en medium

Y funciona. Hasta que quieres agregar una cuarta plataforma, o cambiar la lógica de una sin tocar las otras, o escribir tests aislados para cada integración. En ese momento el if-else se convierte en un problema.

Lo que apliqué fue el patrón Strategy: cada plataforma es un adapter independiente que implementa la misma interfaz. La Lambda no sabe qué plataforma está usando — solo llama a publish() y el adapter se encarga del resto.

El contrato es mínimo e intencional:

from abc import ABC, abstractmethod

class PublishingAdapter(ABC):
    @abstractmethod
    def render(self, post: dict, blog_base_url: str) -> dict:
        """Construye el payload listo para enviar a la API de la plataforma."""

    @abstractmethod
    def publish(self, post: dict, blog_base_url: str) -> dict:
        """Publica o actualiza el post. Devuelve: action, platform, platform_id, url, title."""

Y el facade BlogPublisher es el punto de entrada único. Se instancia con el nombre de la plataforma y delega todo al adapter correspondiente:

class BlogPublisher:
    @classmethod
    def _default_registry(cls):
        from adapters.devto import DevToAdapter
        from adapters.hashnode import HashnodeAdapter
        return { "devto": DevToAdapter, "hashnode": HashnodeAdapter }

    def __init__(self, platform: str, **adapter_kwargs) -> None:
        self._adapter = self._registry[platform](**adapter_kwargs)

    def publish(self, post: dict, blog_base_url: str) -> dict:
        return self._adapter.publish(post, blog_base_url)

Ahora agregar Medium o cualquier otra plataforma es crear un archivo nuevo, implementar la interfaz y registrarlo. Nada más cambia.

El handler: limpio porque la complejidad está en otro lado

Con esa estructura, el handler de la Lambda queda legible. La lógica de orquestación es clara porque cada responsabilidad está donde debe:

results: list[dict] = []
for publisher in publishers:
    try:
        result = publisher.publish(post, blog_base_url)
        results.append(result)
    except (RuntimeError, NotImplementedError) as e:
        results.append({"platform": publisher.platform, "error": str(e)})

succeeded = [r for r in results if "error" not in r]
status_code = 200 if not failed else 207  # 207 Multi-Status
return _response(status_code, {
    "message": f"Published on {len(succeeded)}/{len(results)} platform(s)",
    "results": results,
})

Si Dev.to falla pero Hashnode tiene éxito, la Lambda devuelve 207 con el detalle de cada resultado. El problema está localizado — no explota todo.

Otros detalles que sumaron a la solidez del sistema:

Secretos desde AWS Secrets Manager, no como env vars de la Lambda. Se cachean en memoria para no pagar el costo de una llamada a Secrets Manager en cada warm start.
Sin requests: todo el HTTP usa urllib de la stdlib. Mantiene el zip de la Lambda liviano y sin dependencias externas.
Upsert en los adapters: Dev.to busca por título exacto antes de crear — si ya existe, hace PUT. Hashnode busca por slug. Sin artículos duplicados aunque el webhook se dispare dos veces.
Conversión de Portable Text a Markdown implementada a mano en utils/portable_text.py, también sin dependencias externas.

Dónde entró el vibe coding — y dónde no

Seré honesto: usé vibe coding en este proyecto. Bastante. Le pedí a Claude que generara los adapters de Dev.to y Hashnode, que implementara la conversión de Portable Text, que escribiera los tests de integración.

Y funcionó bien. Rápido.

Pero hay algo que el vibe coding no pudo hacer por mí: decidir la arquitectura.

Cuando llegué con "necesito publicar un post en varias plataformas", lo que obtuve en una primera iteración fue exactamente el if-else gigante que describí arriba. Funcionaba. Pero yo sabía que no era lo que quería — porque conozco el patrón Strategy, porque he visto ese tipo de código crecer y volverse imposible de mantener, porque entiendo qué significa extensibilidad en este contexto.

La conversación que tuve para llegar al diseño final no fue "hazlo", fue "implementa un adapter para Dev.to que extienda esta clase abstracta, con estos métodos, siguiendo este contrato". Eso requería saber qué pedir.

El vibe coding no reemplaza el criterio de diseño. Lo amplifica. Si sabes lo que quieres construir, puedes construirlo mucho más rápido. Si no lo sabes, aceleras hacia el lugar equivocado.

Agregar una nueva plataforma son exactamente 4 pasos

Eso es lo que me gusta de cómo quedó. Si mañana quiero publicar también en Medium (el adapter está como TODO por ahora), el proceso es:

Crear adapters/medium.py implementando PublishingAdapter
Registrarlo en adapters/init.py
Añadirlo al registry en adapters/base.py
Agregar el manejo de credenciales en lambda_function.py

Nada más cambia. El handler no se toca. Los tests existentes siguen pasando.

Ese nivel de extensibilidad no llegó por accidente. Llegó porque antes de escribir la primera línea, pensé en cómo quería que se viera el código cuando tuviera que cambiarlo.

Conclusión

No estoy en contra del vibe coding — lo uso seguido y me parece una herramienta genuinamente poderosa para acelerar la ejecución. Pero hay un prerequisito que a veces se omite en la conversación: funciona mejor cuando quien lo usa tiene criterio técnico para guiarlo.

Patrones de diseño como Strategy, principios como separación de responsabilidades, decisiones como "la complejidad va en el adapter, no en el handler" — esas cosas no las aprende el modelo por ti. Las aprendes trabajando, equivocándote, refactorizando código que creciste.

Y cuando las tienes internalizadas, el vibe coding se convierte en lo que debería ser: un multiplicador, no un atajo.

El código completo está en GitHub si quieres revisarlo.

¿Usas vibe coding en tus proyectos? ¿Cómo lo combinas con las decisiones de arquitectura? Me interesa leer cómo otros están resolviendo esto.

Agregar un CDN parece obvio. Hasta que rompe tus deployments

David De Los Santos Cuy Sánchez — Wed, 18 Mar 2026 23:59:08 +0000

Todos los equipos de infraestructura tienen una lista de cambios que parecen ganancias rápidas. Agregar un CDN, mejorar los tiempos de carga, y seguir adelante. Suena como una tarea de una tarde. No lo es.

Hace poco pasé por una implementación de CDN en una plataforma web en producción. El tipo de proyecto donde el ticket se estima en horas y termina tomando días — no porque la tecnología sea complicada, sino porque el sistema es más frágil de lo que nadie esperaba.

Esto es lo que aprendí.

La promesa

Los beneficios de un CDN son reales y están bien documentados.

La latencia cae significativamente. Servir assets desde un nodo edge cercano al usuario, en lugar de enrutar cada request de vuelta al origen, es una ganancia directa — especialmente para usuarios distribuidos globalmente.

Obtenés visibilidad que antes no tenías. Con un CDN frente a tu aplicación, empezás a ver los patrones de tráfico con una resolución diferente. Granjas de bots, picos geográficos inusuales, tasas de requests anómalas — cosas que antes eran invisibles se vuelven observables. Eso solo ya justifica el costo de implementación en muchos casos.

La resiliencia mejora. El contenido cacheado sigue sirviéndose incluso cuando el origen tiene problemas. Para una plataforma con mucha carga de lectura, esto cambia los modos de falla de manera significativa.

Qué pasa en realidad cuando simplemente lo "encendés"

Acá es donde vive la complejidad.

Invalidación de caché en cada release. Si los cache headers no están configurados correctamente, los usuarios verán estilos desactualizados, layouts rotos o JavaScript obsoleto después de cada deployment. Es el problema más común y el que genera más tickets de soporte. La solución requiere coordinar el pipeline de deployment con la estrategia de purga de caché del CDN — algo que rara vez existe antes de implementar un CDN.

Políticas de seguridad que no sabías que faltaban. Un CDN expone tus response headers a un escrutinio que una conexión directa al origen no hace. De repente, la ausencia de una Content Security Policy, headers HSTS faltantes, o cookies mal configuradas se vuelven visibles. Estos no eran problemas nuevos — siempre estuvieron ahí. El CDN simplemente los hizo aflorar. Eso es útil, pero es scope creep que nadie planeó.

Cadenas de redirecciones que se rompen silenciosamente. Los 301s y 302s que funcionaban bien en el origen pueden comportarse de manera inesperada cuando un CDN empieza a cachearlos o cortocircuitarlos. Una redirección que antes tomaba dos saltos ahora puede crear un loop, o no redirigir del todo si el CDN está sirviendo una respuesta cacheada de la ubicación incorrecta.

Impacto en SEO por headers mal configurados. Las canonical tags, los cache-control headers para crawlers y el manejo correcto de variantes de URL (con/sin trailing slash, www vs. sin www) necesitan configurarse explícitamente. Si se hacen mal, se pueden introducir problemas de contenido duplicado o impedir que los motores de búsqueda indexen las páginas correctas.

Por qué los cambios de infraestructura revelan debilidades en la arquitectura

Esta es la parte que me parece genuinamente interesante.

Cuando el CDN empezó a comportarse mal en staging, el instinto fue culpar a la configuración del CDN. Pero la mayoría de los problemas los rastreamos hasta issues preexistentes en la capa de aplicación: assets sin nombres de archivo versionados, headers que nunca se setearon porque "el origen se encargaba de eso", lógica de redirecciones dispersa en múltiples lugares sin una única fuente de verdad.

El CDN no creó esos problemas. Los hizo imposibles de ignorar.

Es un patrón que he visto repetidamente. Introducir una nueva capa de infraestructura — ya sea un CDN, un API gateway, un service mesh o incluso un load balancer — no solo cambia cómo fluye el tráfico. Cambia lo que podés ver sobre tu sistema. Y lo que podés ver siempre revela cosas que estaban escondidas.

Un CDN bien implementado mejora la experiencia del usuario. Uno mal implementado la degrada de maneras difíciles de diagnosticar, porque los síntomas (estilos rotos, contenido incorrecto, redirects fallidos) parecen bugs de aplicación, no problemas de infraestructura.

Qué fue lo que realmente funcionó

El enfoque que estabilizó la implementación:

Nombres de archivo de assets versionados desde el pipeline de build. Cada archivo JS y CSS recibe un hash de contenido en su nombre. El CDN puede cachear agresivamente con TTLs largos, y la invalidación de caché deja de ser una preocupación en los deployments. Las URLs de los archivos viejos simplemente dejan de ser solicitadas.

Políticas de caché explícitas por patrón de path. Assets estáticos: TTL largo, inmutables. Páginas HTML: TTL corto o sin caché, siempre revalidadas. Rutas de API: bypasseadas completamente. Esto requirió mapear toda la superficie de routing de la aplicación antes de tocar la configuración del CDN.

Un paso de purga de caché en el CI/CD. Después de cada deployment a producción, el pipeline dispara una purga de los paths que sirven HTML vía la API del CDN. Es simple de implementar, pero requiere tratarlo como parte del proceso de deployment, no como algo que se agrega después.

Headers de seguridad movidos al edge del CDN. CSP, HSTS, X-Frame-Options — configurados una sola vez a nivel CDN en lugar de por aplicación. Más fácil de auditar, consistente en todos los orígenes.

Lecciones aprendidas

La lección operativa es directa: no estimes una implementación de CDN mirando el CDN. Estimala mirando qué tan preparada está tu aplicación para recibirlo.

La lección más profunda tiene que ver con lo que realmente son los cambios de infraestructura "simples". No son simples. Son familiares. Y esa familiaridad es lo que los hace peligrosos. Los ingenieros los subestiman porque han visto funcionar CDNs antes. Pero los han visto funcionar en otros contextos, sobre otras aplicaciones, con otros supuestos implícitos.

En ingeniería, "esto ya lo hicimos antes" no es lo mismo que "esto va a ser sencillo".

El cambio de infraestructura fue exitoso. La experiencia del usuario mejoró de manera medible. Pero lo que voy a recordar de este proyecto no son los números de performance — sino la lista de cosas que encontramos en el camino que no tenían nada que ver con CDNs y sí mucho con cómo el sistema había crecido sin un dueño claro para algunos de sus comportamientos fundamentales.

Esa lista se convirtió en un backlog. Ese backlog se convirtió en un sistema mejor.

Cómo la IA Finalmente Me Ayudó a Lanzar el Blog que Venía Postergando desde 2024

David De Los Santos Cuy Sánchez — Tue, 17 Mar 2026 17:35:19 +0000

Todo ingeniero tiene un cementerio de side projects. En el mío había un blog. Dos veces.

La primera vez que pensé en crear un blog fue a principios de 2024. Tenía cosas que decir — cosas reales, de proyectos reales. Decisiones de arquitectura que salieron mal. Patrones serverless que se veían perfectos en la pizarra y se desmoronaban en producción. Las historias de guerra que uno acumula después de años construyendo sistemas de los que otros dependen.

Pero entonces: arrancó un nuevo sprint. Un cliente necesitaba algo urgente. Una migración de infraestructura no podía esperar. Y el borrador del blog se quedó en una nota de Notion, acumulando polvo digital, junto a otros tres proyectos de "ya lo retomo cuando pueda".

Esto no pasó una vez. Pasó dos. Dos intentos. Dos borradores abandonados. El mismo patrón cada vez: dos pasitos para adelante, luego la vida real aparecía y cerraba silenciosamente la pestaña.

El Problema Real No Era el Tiempo. Era la Energía de Arranque.

Lo que eventualmente entendí fue esto: no es que no tuviera tiempo. Era que el costo de sentarme a producir algo listo para publicar era suficientemente alto como para que siempre perdiera contra cualquier otra cosa que compitiera por mi atención.

Escribir un post implicaba: redactar, editar, encontrar o crear una imagen, darle formato para la web, pensar en SEO, publicarlo, y luego repetir todo eso para cada plataforma donde quería que viviera. Cada uno de esos pasos es pequeño por separado. Juntos, forman una pared.

Y si eres alguien que diseña sistemas profesionalmente, sabes exactamente qué pasa cuando la fricción en un proceso es demasiado alta: la gente lo esquiva o lo abandona.

Yo estaba esquivando mi propio blog.

Entonces Decidí Tratarlo Como un Problema de Ingeniería

En 2025 finalmente construí el blog — pero lo encaré de forma diferente. En lugar de buscar una fuerza de voluntad que no tenía, reduje la energía de arranque.

El blog en sí fue construido principalmente con vibe coding usando Claude Code. No voy a pretender que escribí cada línea desde cero. Tenía una visión clara de lo que quería: un sitio de portafolio rápido y limpio, con sección de blog, soporte de internacionalización, Sanity CMS en el backend, y algo que se sintiera como yo y no como un template genérico. Claude Code me ayudó a pasar de idea a implementación funcionando mucho más rápido de lo que hubiera podido solo. Yo guié el proceso, revisé el código, tomé las decisiones — pero no me quedé bloqueado en los detalles de implementación.

¿Las imágenes? Generadas con Gemini (Nano Banana Pro). Escribo un prompt descriptivo para cada post, enfocado en un estilo de ilustración tech limpio, y obtengo un visual que le hace justicia al artículo sin tener que pasar horas en Figma ni buscar stock photos que "más o menos" sirvan.

El contenido — incluyendo este post — está escrito con asistencia de IA. No generado de forma automática y publicado a ciegas, sino redactado, refinado y moldeado con la IA como compañero de pensamiento. Las ideas son mías. Las experiencias son mías. La IA me ayuda a sacarlas de la cabeza y llevarlas a la página más rápido.

De Qué Va a Tratar Este Blog

Más allá de la historia de cómo fue construido, quiero ser claro sobre lo que estoy haciendo acá.

Este blog va a cubrir cosas que realmente viví durante mi carrera como Cloud Architect y Software Engineer. Eso incluye:

Decisiones de arquitectura y los trade-offs reales que hay detrás
Sistemas serverless y event-driven — cuándo funcionan y cuándo no
Integrar sistemas legacy sin romper producción
Diseño de SaaS multi-tenant en AWS
Liderazgo técnico y cómo explicar arquitectura a personas que no son arquitectos
Y sí, alguna que otra anécdota del campo — porque ciertas lecciones solo quedan cuando vienen con una historia

El objetivo no es ser un sitio de tutoriales. Hay miles de esos. El objetivo es compartir el razonamiento detrás de las decisiones — el por qué, no solo el cómo.

Un Detalle de Ingeniería Más: El Pipeline de Publicación Cruzada

Porque al parecer soy incapaz de resolver un problema sin construir también un sistema alrededor de él:

Armé un pipeline para que cuando publique un post aquí, se replique automáticamente a Hashnode y dev.to. Escribir una vez, publicar en todas partes.

Si eres desarrollador, ya sabes por qué esto importa. La mejor estrategia de distribución de contenido es la que realmente vas a mantener. Copiar y reformatear posts manualmente en tres plataformas distintas es exactamente el tipo de fricción que mató mis intentos anteriores. Así que lo eliminé.

El sistema maneja las diferencias de formato entre plataformas, propaga el contenido, y me deja enfocarme en escribir en lugar de en la logística de publicación.

El Punto Principal

No estoy escribiendo este post para decirte que la IA es mágica. No lo es. Es una herramienta — y como cualquier herramienta, su valor depende completamente de cómo la uses.

Lo que la IA hizo por mí fue bajar el costo de empezar. No reemplazó el criterio, la experiencia ni las ideas. Eliminó la barrera de energía de arranque que había mantenido un blog a medio terminar en mi cementerio de proyectos por más de un año.

Para ingenieros en particular, creo que esta es la aplicación más subestimada de estas herramientas ahora mismo. No reemplazar tu trabajo central — sino eliminar la fricción circundante que te impide lanzar las cosas que realmente te importan.

El blog existe ahora. Lo estás leyendo.

Eso ya es suficiente prueba de concepto para mí.

Por qué pusimos un CDN frente a nuestro balanceador de carga (y por qué las cookies fueron el verdadero problema)

David De Los Santos Cuy Sánchez — Fri, 13 Mar 2026 05:50:07 +0000

Agregar un CDN parece algo obvio. Hasta que es lo único que se interpone entre tú y un deployment roto…

El contexto

Estábamos en medio de dos cambios en paralelo: un rediseño completo del sitio web y una migración de servidores. Ambos estaban planeados, con scope definido, y avanzando sin problemas... hasta que notamos que un segmento de usuarios empezó a tener fallas después de la migración. No todos. No de forma consistente. Pero suficiente para ser un problema real.

El culpable: las cookies.

El problema

El servidor anterior había acumulado cookies con el tiempo. El nuevo servidor introdujo las suyas propias. Cuando un usuario llegaba en medio de la migración —todavía cargando las cookies antiguas y recibiendo las nuevas del sitio rediseñado— el payload combinado superaba el tamaño máximo aceptado por el balanceador de carga: 16 KB.

Este límite no es arbitrario. Es una restricción dura que aplican la mayoría de los balanceadores de carga y CDNs a nivel HTTP. Una vez que lo cruzas, las solicitudes empiezan a fallar silenciosamente o a ser rechazadas.

Para hacerlo más complejo: el dominio no estaba bajo nuestro control directo. Apuntaba al balanceador mediante un CNAME de un proveedor DNS externo. Eso significaba que no podíamos cambiar el ruteo sin coordinar con terceros, ni tocar la configuración del balanceador directamente.

Por qué era difícil

Lo complicado no era el fix técnico. Era la restricción principal: no podíamos permitirnos ninguna afectación al usuario durante el cambio.

El error too_many_redirects solo aparecía para usuarios con payloads de cookies grandes —sesiones específicas, navegadores específicos, rutas específicas entre el sistema viejo y el nuevo—. Un cutover total habría expuesto a todos al riesgo. Y hacer rollback tampoco era una opción limpia, porque la migración ya estaba parcialmente en vivo.

Necesitábamos una solución que:

Interceptara las solicitudes antes de llegar al balanceador
Limpiara las cookies basándose en una whitelist (conservando solo lo necesario)
Solo modificara el request, sin disparar redirects
Pudiera desplegarse sin tocar el registrador del dominio ni el balanceador

La solución

Introdujimos una capa de CDN entre el DNS y el balanceador, y cambiamos el CNAME para que apuntara al CDN en lugar de ir directamente al balanceador.

En el edge del CDN, adjuntamos una función Lambda@Edge que se ejecutaba en cada solicitud entrante. Su trabajo era simple: leer las cookies, aplicar la whitelist, eliminar todo lo demás, y reenviar el request limpio hacia abajo.

Sin redirects. Sin pérdida de sesión para las cookies en la whitelist. Sin cambios en el código de la aplicación ni en la configuración del balanceador.

La arquitectura final quedó así:

[DNS → Firewall] → CDN → (Lambda@Edge) → Balanceador → Cluster

El CDN nos dio la capa de ejecución en el edge que necesitábamos. La función Lambda@Edge nos dio control preciso a nivel de request. Y como solo modificábamos los headers del request —nunca la respuesta—, el loop de too_many_redirects nunca se disparó.

Lo que aprendimos

Entiende qué está bajo tu control y qué no. El dominio estaba fuera de nuestro registro. El balanceador tenía límites fijos. Las cookies existentes de los usuarios no eran negociables. Trabajar dentro de esas restricciones moldeó cada decisión.

El CDN no era el objetivo, era el habilitador. No lo agregamos por rendimiento ni caché. Lo agregamos porque nos daba una capa programable exactamente donde la necesitábamos: entre el usuario y el balanceador.

Whitelist es más seguro que blacklist. En lugar de intentar identificar cuáles cookies causaban el desbordamiento y eliminar solo esas, invertimos el enfoque: definir qué debe sobrevivir, eliminar todo lo demás. Más simple de mantener, más seguro de desplegar.

Los cambios sin downtime son decisiones de arquitectura, no trucos de deployment. La razón por la que pudimos hacer este cambio sin afectar a los usuarios no fue suerte: fue que la arquitectura nos permitió insertar una nueva capa sin modificar nada de lo que estaba debajo.

Conclusión

La buena arquitectura no siempre se trata del diseño más elegante. A veces se trata de entender cómo interactúan tus sistemas entre sí, identificar dónde tienes apalancamiento real, y elegir el recurso correcto según las restricciones que tienes hoy —no las que quisieras tener—.

Un CDN y una pequeña función Lambda resolvieron lo que parecía un problema de cookies. Pero lo que realmente resolvieron fue un problema de control.

Forem: David De Los Santos Cuy Sánchez

Cómo uso Mermaid para comunicarme con producto, arquitecturar con devs y documentar todo al mismo tiempo

La revelación: código que genera diagramas

El caso real: de 10 escenarios a 4 eventos

Los dos diagramas que más uso y cuándo

Dónde viven los diagramas: la clave de la documentación viva

Por qué Mermaid y no otra cosa

Cómo empezar mañana

Cuando el negocio no es el tuyo: cómo entender el dominio para rediseñar un sistema de facturación con event-driven

El síntoma: una lista interminable de “cuándo facturar”

El proceso: aprender el dominio antes de tocar el código

La solución técnica: AWS EventBridge como bus central

El resultado

La lección de arquitectura

El algoritmo que se moría en CDMX: de O(10 ) a una consulta SQL

El algoritmo que se moría en CDMX: cómo pasé de O(10⁷) a una consulta en base de datos

Cómo funcionan los teléfonos en México (lo mínimo necesario)

La primera versión: el infierno de los for

El insight clave: el problema no era el algoritmo, era la herramienta

La solución: tablas temporales + JOINs + bulk insert

1. Las reglas del IFT se convirtieron en tablas

Cómo conecté Slack, Notion, Google Calendar y Sanity con Claude como orquestador para automatizar mi blog

El problema que quería resolver

La arquitectura del sistema

Cómo funciona en la práctica

Paso 1: La idea nace en Slack

Paso 2: Claude procesa y registra en Notion

Paso 3: Priorización semanal

Paso 4: Redacción con el skill blog-tech-writer

Paso 5: Imagen y distribución

Paso 6: Publicación en Sanity

Lo que aprendí construyendo esto

¿Vale la pena el setup inicial?

Cómo rediseñamos un backend completo sin detener la operación

El sistema llevaba cinco días en producción cuando llegué

Por qué es difícil cuando el sistema ya está en producción

Lo que aprendí estando del lado que nadie quiere estar

La migración de DynamoDB a PostgreSQL

Lecciones que me quedaron

Conclusión

Vibe coding funciona. Pero primero necesitas saber diseño de software

La idea: Sanity como hub de publicación

Por qué no usé un if-else gigante

El handler: limpio porque la complejidad está en otro lado

Dónde entró el vibe coding — y dónde no

Agregar una nueva plataforma son exactamente 4 pasos

Conclusión

Agregar un CDN parece obvio. Hasta que rompe tus deployments

La promesa

Qué pasa en realidad cuando simplemente lo "encendés"

Por qué los cambios de infraestructura revelan debilidades en la arquitectura

Qué fue lo que realmente funcionó

Lecciones aprendidas

Cómo la IA Finalmente Me Ayudó a Lanzar el Blog que Venía Postergando desde 2024

El Problema Real No Era el Tiempo. Era la Energía de Arranque.

Entonces Decidí Tratarlo Como un Problema de Ingeniería

De Qué Va a Tratar Este Blog

Un Detalle de Ingeniería Más: El Pipeline de Publicación Cruzada

El Punto Principal

Por qué pusimos un CDN frente a nuestro balanceador de carga (y por qué las cookies fueron el verdadero problema)

El contexto

El problema

Por qué era difícil

La solución

Lo que aprendimos

Conclusión

La primera versión: el infierno de los `for`