Si hay algo que todo programador descubre tarde o temprano, es que las estructuras de datos están en todas partes. Matrices, listas, grafos y muchas otras nos permiten modelar problemas del mundo real de forma eficiente, convirtiendo información compleja en algo que nuestras aplicaciones pueden procesar rápido y con precisión.

Sin embargo, hay estructuras de datos que han sido ‘olvidadas’, o que, al menos, no se les ha dado la importancia que merecen.

Una de ellas son los heaps (o montones). ¿Los has escuchado? 🧐

Hoy te explicaremos qué son, por qué son tan útiles y cuándo deberías aplicarlos.

¿Te ha pasado que un gran artista se va a presentar en tu ciudad y conseguir los tiquetes es literalmente un infierno 😵?

Bueno, ya te imaginarás los grandes retos a los que se enfrentan quienes desarrollan sistemas de ticketing: el cuello de botella inicial para ingresar al sitio, la escalabilidad de los recursos del sitio y la resiliencia para no caerse.

Pero hoy nos centraremos en hablar de un escenario muy específico.

Condiciones de carrera

Si trabajas en equipo o has contribuido a proyectos open-source, probablemente sepas lo intimidante que es leer por primera vez el código que otros escribieron.

No estás solo, de hecho, me atrevería a decir que esa sensación siempre existirá 😁, sin importar la experiencia que tengas.

Y, es que claro, nadie dijo que eso tenía que ser una tarea fácil. De hecho, depende en gran medida de las habilidades de redacción de la otra persona. Si su código es malo, leerlo será difícil.

Pero, como muchas otras cosas, estos son gajes del oficio.

Cuando se trata de escalar un sistema y, a su vez, asegurar una alta disponibilidad, entra en juego la replicación de la base de datos.

Y es que, así como replicamos servicios —para que en caso de que uno falle, el otro siga atendiendo las solicitudes—, así mismo es posible hacerlo con las bases de datos, manteniendo una o más copias actualizadas.

¿Has escuchado alguna vez hablar de “read replicas”, “multi-primary clusters” o “failover automático”? Pues todas son caras de la misma moneda.

Hoy, entraremos en detalle en cada una de estas técnicas de replicación y en cuándo conviene aplicar cada una.

…bueno, asumiendo que ya lo usas.

Terraform es una herramienta de código abierto que sirve para provisionar y gestionar infraestructura en la nube mediante código, en lugar de hacerlo manualmente, llendo a cada su sitio web y luego… 😴.

💡 La infraestructura son los recursos físicos y virtuales que ejecutan las aplicaciones; servidores, redes, bases de datos, etc.

La idea tras Terraform es muy simple: tú escribes archivos .tf en los que especificas cómo quieres que sea tu infraestructura: cuántas máquinas, qué redes, qué bases de datos, en qué proveedor de nube, etc.

Si eres developer desde hace un tiempo, seguramente ya estés acostumbrado a la siguiente pregunta:

“¿Para cuándo lo puedes tener listo?“

Bien sabemos que definir los plazos de entrega para un proyecto no es una tarea fácil. De hecho, el mismo Douglas Hofstadter tenía razón cuando dijo:

“Siempre toma más tiempo de lo esperado, incluso cuando tienes en cuenta la Ley de Hofstadter“.

Cuando un sistema empieza a crecer, nos vemos en la necesidad de escalar y, en la mayoría de casos, la mejor opción es hacerlo horizontalmente; es decir, añadiendo más nodos.

❗ Con un nodo, nos referimos a:

• Un servidor físico

• Una máquina virtual

• Un contenedor

• O incluso un pod de Kubernetes

Escalar horizontalmente no solamente es bueno en términos de rendimiento, sino también en cuando a disponibilidad.

En realidad, cuando distribuimos la carga entre varios nodos, nos aseguramos de que nuestros usuarios puedan acceder más fácilmente a una instancia de la aplicación y que obtengan la menor latencia posible.

Cuando alguien nos explica qué son los contenedores, la definición más común suele ser algo como:

“Una cajita que aisla tu aplicación junto con todo lo que necesita para funcionar para que se pueda ejecutar en cualquier lado“.

Y aunque la definición es correcta, en realidad, un contenedor no se encuentra completamente aislado del mundo que lo rodea, sino que se conecta a una red que es internamente gestionada por Docker.

¿Recuerdas los switches?

¿Te has preguntado cómo programan los seniors?

Aunque no hay una fórmula exacta que podamos seguir al pie de la letra, sí existen principios que todo buen informático debería seguir.

Nuestro propósito hoy será explicarte 3 de estos principios que, aunque no son los únicos, sí son esenciales si quieres que tu código sea mucho mejor (al final verás por qué 🤭).

Puede que ya los conozcas, pero muchos de ellos han sido malinterpretados con el paso del tiempo, así que nos tomaremos el tiempo de aclararte las cosas tal y como son.

Parte de nuestra filosofía como comunidad de divulgación para informáticos es que, un buen sistema no se construye solo con código limpio, sino que también necesita bases sólidas que lo sostengan.

Así que puedes haber escrito el código más elegante y sofisticado del mundo, pero sin un buen diseño, difícilmente sea óptimo para producción.

Y cuando hablo de diseño no me refiero a la interfaz gráfica.

💡 El diseño de un sistema es la forma en que están organizados sus componentes y cómo interactúan entre sí.

¿Cuántas veces has utilizado localhost? Seguro has escrito miles de veces 127.0.0.1 para conectarte a servicios y aplicaciones localmente. Y aunque siempre nos han enseñado que no hay ninguna diferencia entre estos 2, puede que estemos pasando algunos detalles por alto.

Alguna vez mentoramos a alguien (que sí, que también ofrecemos mentorías personalizadas 😉) que llevaba horas intentando conectarse a una base de datos MySQL que tenía levantada en su máquina.

MySQL escuchaba todas las llamadas de 127.0.0.1, pero el cliente intentaba conectarse a localhost. Nuestro amigo no pudo conectarse hasta que se dio cuenta de lo que te contaremos a continuación.

¿Qué es localhost?

JavaScript nació en 1995, cuando los navegadores necesitaban un lenguaje ligero y fácil de aprender para añadir interacción a las páginas web. Para ese entonces, el HTML todavía era estático.

El lenguaje parecía casi una creación divina, pues la primera versión de JavaScript fue construida en tan solo 10 días.

Desde un principio JavaScript fue un lenguaje pensado:

• Para ser interpretado, por lo que se ejecuta línea por línea a través de un intérprete, sin necesidad de compilarse previamente a código máquina.

• Con un sistema de tipos dinámico. Es decir, no declaras explícitamente el tipo de las variables, sino que este se asigna en tipo de ejecución.

• Carente de módulos y otras herramientas. Eso vino después cuando se introdujo ECMAScript.

⚠️ Hace poco, hicimos un episodio explicando cómo funcionan los LLMs. Te recomendamos leerlo antes de ver este artículo.

Uno de los temas en tendencia del momento es RAG, o ‘Generación Aumentada por Recuperación’, por sus siglas en inglés.

Somos conscientes de que los LLMs tienen una limitación temporal: son entrenados solo hasta cierta fecha. Esto dificulta las cosas cuando necesitamos preguntarle por hechos más recientes, o incluso cuando necesitamos que nos ayude con nuestra propia información.

Para ser claros, imagina que debes desarrollar un asistente inteligente para una empresa, y este debe poder dar respuestas basándose en la base de conocimiento de un producto.

¿Qué pasa cuando abres un sitio en Google y no carga?

Pasas de largo a otro resultado, ¿verdad?

Los humanos no podemos perder nuestro valioso tiempo en tales minucias.

Un buen desarrollador debería tener claro que el software va más allá de programar. A veces, la importancia está en los detalles: decisiones arquitectónicas, buenas prácticas y la configuración de la infraestructura.

“Supongamos, sin embargo, que en lugar de llamarlos errores los llamáramos bombas de tiempo…”

Watts S. Humphrey

Todos estamos muy emocionados con la IA. Si GPT-4 logró sorprendernos, ni nos imaginamos lo que se viene con la llegada de GPT-5.

Pero entre tanta euforia, poco o nada nos hemos cuestionado sobre la seguridad en estos entornos, y cuáles son los riesgos que presentan.

MCP (o Model Context Protocol) ha permitido que los modelos trasciendan de sí mismos e interactuen más allá de sus límites. Pero varios servidores MCP populares ya fueron encontrados vulnerables.

2025 ha sido el año de automatización.

El avance de la inteligencia artificial nos ha llevado a aprovecharla como nunca antes para automatizar todo lo que sea posible.

Pero automatizar también implica utilizar otras técnicas más allá de solo escribir prompts o conectar un LLM a un servicio externo con MCP.

En algunas ocasiones, también necesitamos extraer información de un sitio web o incluso interactuar con él; de eso se trata justamente el web scraping.

¿Tienes cuenta de Pinterest? Esta particular red social enfrentó un crecimiento acelerado en sus inicios, por allá en el 2010. Eso se convirtió en un verdadero reto para ellos, pues tuvieron que tomar decisiones técnicas apresuradas mientras se les venía una avalancha de usuarios encima.

Hace ya un tiempo, Yashwanth Nelapati y Marty Weiner dieron una charla en la que hablaron de sus aciertos, desaciertos, y en todo caso, como lograron optimizar la arquitectura de Pinterest al máximo.

De esa charla hay bastantes lecciones que hoy todavía son útiles, y que además nos servirán para explicarte otros conceptos.

Tráete un café y empecemos.

En el episodio de hoy, asumiremos que no te olvidas de escribir los tests unitarios, VERDAD?! 😈

Si los haces, probablemente en algún momento te hayas encontrado con una situación en la que debías probar una función que dependía de algo externo, como una base de datos, una API, un servicio de pagos, un archivo en disco, etc.

Escúchame bien: no deberías de invocar esas dependencias directamente dentro de una prueba unitaria.

Si estás leyendo esto, es muy probable que ya conozcas las estructuras de datos de toda la vida: los arreglos, las listas enlazadas, las pilas, las colas, los grafos, los árboles (¡oh dichosos árboles! 🤭), etc.

En el mundo del software, utilizamos las estructuras de datos como una forma de organizar y almacenar la información para que pueda usarse de manera eficiente.

Para que te hagas a una idea más clara, imagina que necesitamos verificar si un número K se encuentra en una larga lista de números. Luego, si K no existe, entonces se añade, o si existe, no se añade.

Aquí nuestra labor es hallar la estructura de datos más adecuada para almacenar la larga lista de números.

Todos, en algún momento de nuestras carreras, nos hemos enfrentado a este famoso error:

Sepas cómo solucionarlo o no, es necesario que profundicemos en las razones por las que se producen los errores CORS, cómo configurarlo correctamente para protegernos de ataques, y de dónde surge esta política.

Ve por un café y prepárate para aprender todo lo que deberías saber sobre CORS ☕⬇️

Los agentes de IA están cada día agarrando más popularidad, y hace poco se nos ocurrió una idea: si un agente puede capacitarse para hacer prácticamente cualquier cosa, ¿por qué no hacer uno que resuelva bugs?

¡Bingo! 💥

Eso es precisamente lo que vamos a hacer hoy; lo mejor de todo es que solo utilizaremos Python y GPT-4o, aunque cabe aclarar que estas y las demás tecnologías que usaremos son solo una preferencia nuestra, y puedes usar las que más se adapten a tus necesidades (o gustos).

Lo mejor de todo es que al terminar, podrás subir este proyecto a tu portafolio y mostrar algo novedoso a los demás.

¡El tiempo si que pasa rápido! Ya ha corrido medio 2025 y Junio no nos ha tenido paciencia tampoco 😅.

Y es que resulta que en Enero hicimos un carrusel en Instagram en el que hablamos sobre los temas más calientes que deberías aprender este año. Aún estas a tiempo, por si lo quieres intentar.

Precisamente, hoy te traemos un episodio en el que te daremos un recorrido completo por todo lo que necesitas saber de Git.

Así que hoy, por lo menos, podrás chequear uno de los elementos de la lista 🔥.

Si aún piensas que hacer caching consiste únicamente en poner a Redis o Memcached entre el servidor y la base de datos, necesitas leer este artículo urgentemente 🚨.

Y es que puede que hacer eso sí funcione.

Pero también tienes que tener en cuenta que implementar caching tiene más ciencia de la que podrías pensar. De no hacerse de la manera correcta puede provocar lecturas inconsistentes, perdida de datos y cualquier otro tipo de bugs raros.

Es por tal razón, que hoy te hablaremos de las distintas estrategias de caché que existen, para que siempre escojas la que mejor se adapte a las necesidades de tu proyecto.

La programación, tal como la conocemos, está cambiando.

La inteligencia artificial ya es capaz de escribir código, y aunque aún necesita supervisión humana, es evidente que pronto lo hará incluso mejor que nosotros en muchos casos.

Esto plantea una pregunta inevitable: ¿cuál será entonces nuestro nuevo rol como programadores?

Algunas voces influyentes en la industria del software incluso se preguntan si seguiremos necesitando interfaces gráficas, ahora que un chatbot puede interactuar directamente con el usuario y ejecutar tareas por él.

Estamos muy acostumbrados a solicitarle cosas al servidor, pues ese es el modelo estándar con el que diseñamos aplicaciones: necesitamos algo, se lo pedimos y él nos lo devuelve.

Todos felices ☺️.

Sin embargo, cada día los requerimientos se vuelven más complejos y, por lo tanto, ya no queremos solicitarle algo al servidor, sino que él nos lo envíe apenas lo tenga listo.

Es más común de lo que piensas, solo piensa en chats en vivo, notificaciones, dashboards interactivos… todos requieren que, de alguna forma, el servidor sea el que le hable al cliente, y no al revés.

Migrar de un monolito a microservicios es una decisión sumamente importante, ojo: no necesaria.

En muchas ocasiones hemos hablado de las bondades de los microservicios, como que nos permiten hacer cambios más rápidos y frecuentes, realizar entregas paralelas e independientes entre sí e incluso facilitar el mantenimiento.

Pero también hemos hablado de los desafíos técnicos que conlleva, que es una decisión que debe tomarse con cautela, pues implica reconstruir un barco —si lo vemos metafóricamente— que, en la mayoría de casos, ya zarpó.

Y vaya que reconstruir un barco en altamar no ha de ser tarea fácil 😆.

En un mundo donde tenemos más tecnologías para escoger que problemas que solucionar (es un chiste 😅), lo más común es escoger PostgreSQL y se acabó (chiste x2).

Bueno, en realidad escoger una base de datos es todo un arte, y no se trata solo de seleccionar nuestra tecnología favorita —aunque eso quisiéramos—, sino de entender en profundidad cada uno de los factores involucrados y cómo pueden afectar nuestra aplicación.

Así que en el episodio de hoy, analizaremos todos esos detalles e intentaremos llegar a una clasificación adecuada que te permita escoger una base de datos más rápido que en lo que escogerías Postgres (último chiste 😂).

Empecemos por preguntarnos…

Es probable que, en este punto, aún no tengas ni idea de para qué carajos se supone que sirve el famosísimo DDD (o Diseño Orientado al Dominio, por sus siglas en inglés).

Pero tranquilo, que hoy lo desglosaremos al máximo para que puedas entender su verdadero propósito, y cómo puedes utilizarlo a tu favor para desarrollar software.

¡Empecemos! ☕

Ya hay movimiento.

Ya hay historias. Ya hay preguntas reales.
Y sí… ya hay comunidad.

Quiero que imagines el siguiente escenario: estás almacenando la información de tus usuarios en una base de datos distribuida —esta última palabra es clave—, pues se encuentra repartida en 3 servidores A, B y C.

Cuando vayamos a guardar registros, queremos distribuir la información tan uniformemente como sea posible, es decir, que haya una cantidad de registros similar en cada uno de los servidores.

Para ello, es muy común utilizar una técnica conocida como mod-N hashing, en la que:

1. Se aplica una función de hash a una clave (como el ID del registro a insertar).

2. Posteriormente, se saca el módulo entre el número de servidores que tenemos, así:

Ya está abierto.

Después de días contándote la historia,

compartiéndote cómo nació todo esto

y hablándote de lo que estamos construyendo…

¿Es posible que un servidor haga cosas por sí solo a las 3 am mientras tú estás durmiendo? 😰.

Sí, tranquilo. No es nada paranormal, y se puede hacer gracias a una poderosa herramienta que tenemos en Linux: cron.

Si administras servidores es 100% necesario que la domines.

En este episodio aprenderemos todo sobre Cron, desde la sintaxis más básica hasta técnicas avanzadas para evitar colisiones entre tareas programadas.

Si has estado pendiente de nuestras redes sociales, seguramente ya hayas visto un video reciente en el que hablamos sobre el auge de MCP o Model Context Protocol.

Si no lo has visto, hazlo 😉 (porque igual lo vas a necesitar).

Tal y como lo dijimos en el vídeo, MCP actúa como el cable USB-C que usas en tu laptop; te permite cargarla, transferir datos, conectar pantallas y hasta cargar otros dispositivos.

Pero en el contexto de MCP, se estandariza la comunicación de los sistemas de IA en general —no solo chatbots— a herramientas externas y fuentes de datos.

No todos están recibiendo estos correos.

De hecho, si te están llegando,

es porque en algún momento levantaste la mano,

te uniste a la newsletter,

Ya me lo han preguntado varios:

“¿Por qué montáis esto en WhatsApp y no en Discord?”

Respuesta rápida<:

Porque no quiero ruido.

Llevo 4 días contándote mi historia.

No por nostalgia.

No para que me aplaudas.

Sino porque sé que, en algún punto,

Había noches donde me iba a dormir a las 2 o 3 de la mañana.

Y me despertaba a las 7 con un solo pensamiento:

seguir.

En 2020 todo se vino abajo

Tenía un trabajo estable, proyectos con Oracle, rutinas claras.

¿Alguna vez has tenido que desarrollar una pasarela de pagos? 😬.

Bueno, realmente no es complicado si entiendes el flujo de pago. Sin embargo, una parte que sí se puede tornar realmente complicada (y que, por supuesto, aprenderemos hoy) es la del manejo de errores.

Durante la realización de un pago, se pueden presentar una cantidad de situaciones: particiones de red, fallas en los sistemas del banco o incluso un timeout.

Nuestro mayor desafío será decidir cuándo es conveniente reintentar el pago y cuándo no.

Mi primer lenguaje fue C.

Mi primera “herramienta” fue un boli Bic.

Quería ser arquitecto.

De esos que diseñan espacios y construyen cosas bonitas.

Hace dos domingos nos quitaron una hora.
A ti te dolió el sueño.
A tu API… le dolió la lógica.

Tiempos desfasados.
Registros duplicados.
Fechas que parecen sacadas de un multiverso.

Todo porque alguien se olvidó de esto:

Las máquinas no entienden el cambio de hora.
Solo entienden UTC.

Si tienes experiencia programando, probablemente ya hayas utilizado patrones.

Los patrones son soluciones reutilizables y probadas para resolver problemas, bien sea en el diseño, la arquitectura o la implementación del software.

Ahora bien, así como hay patrones, también existen los anti-patrones.

Particularmente, en la arquitectura de microservicios, hay algunas prácticas que se consideran anti-patrones y que, a la larga, pueden generar serios problemas.

Me pasaron un Excel con 3.000 registros.

Tenía que subirlos a mano a un CRM.

Una de esas tareas que te quitan la fe en la humanidad (y en los formularios web).

Abrí la hoja, suspiré... y pensé:

Un lunes por la mañana, con los ojos medio cerrados y la agenda ardiendo, me encontré en medio de una mini pesadilla:

Tenía que actualizar datos en dos plataformas diferentes, a mano.

Copiar. Pegar. Repetir. Y no equivocarme.

Tenía dos opciones:

Fue en una integración que parecía fácil.

Unas cuantas rutas REST, una aplicación frontend conectando a un backend, y todo debería funcionar como un reloj.

Pero no.

Cada vez que lanzaba la petición, la API respondía con un glorioso: error 500.

Literal.

Yo pensaba que todo estaba controlado.

Un sistema de reservas, sencillo, funcional, casi elegante.

Hasta que un día la API dejó de responder.

Pero ya podría estarlo.

GPT, Gemini, Claude…

Todas usan algo que tú deberías dominar: APIs.

Sin APIs no hay IA.

Así como organizamos nuestras casas, de vez en cuando hay que organizar también el código.

El ‘refactoring’ o refactorización es una práctica que consiste en mejorar la estructura y claridad del código sin alterar su comportamiento.

Mantener el código organizado no solo nos facilitará su futura comprensión y depuración, sino que también reducirá en gran medida la temida deuda técnica.

En este episodio, nos centraremos en explicarte distintas técnicas probadas con las que puedes refactorizar tu código. Si bien hay unas más simples que otras, al final del día verás como, al aplicarlas todas, tu base de código mejorará drásticamente 🙌.

Netflix no se cae.

Y no es porque tengan duendes mágicos.

Es porque su arquitectura está pensada para algo que la mayoría ignora:

Fallará. Tarde o temprano. Fallará.