Archivo · Blog
Cada artículo sale de algo que construí o que vi romperse: pagos, sistemas distribuidos, IA en producción. Empieza por el tema que te está mordiendo ahora, o baja la lista desde el principio.
Todo el mundo consigue montar una demo que impresiona. Lo que separa la demo del producto son tres disciplinas, y la mayoría de los equipos no tiene ninguna de las tres.
Dos preguntas aparecen en toda empresa: por qué el informe tumbó producción, y por qué el número de mi panel es distinto del tuyo. Las dos tienen la misma causa raíz.
La demo funciona en cinco minutos. Lo que nadie enseña es la capa de evaluación, coste y fallo que separa el prototipo de lo que aguanta a un usuario real.
Tres técnicas que permiten tocar con seguridad un sistema que no escribiste, no entiendes, y no puedes parar.
La prueba no existe para demostrar que el código está bien. Existe para que puedas cambiarlo mañana sin miedo. Ese cambio de objetivo lo reorganiza todo.
Todo gateway reenvía webhooks. Si tu handler no es idempotente, lo vas a descubrir el día en que la misma venta se cuente tres veces.
Las tres siglas más confundidas de la autenticación, qué resuelve cada una, y los errores que aparecen en casi todo el código.
La mayoría de las filtraciones que salen en las noticias no usa técnicas sofisticadas. Usa uno de estos seis fallos, y los seis tienen corrección conocida y barata.
Un guion de seis comandos que convierte "debe de ser la red" en "es la capa X, en el tramo Y".
El servicio arranca bien y empeora a lo largo de los días. Tres causas explican casi todos los casos, y las tres tienen señales distintas.
La elección entre los dos modelos no es de gusto ni de moda. La determina el perfil de tu carga, y hay una cuenta que la decide.
Los bugs que no pasan en tu máquina, no pasan en las pruebas, y pasan en producción. Cómo reconocerlos leyendo código.
Una guía de decisión por problema, y no por estructura. Tienes una necesidad; qué estructura responde, y a qué coste.
Por qué Postgres es bueno en rangos y Cassandra es bueno escribiendo. No es marketing: es el árbol que cada uno eligió, y la cuenta que cada elección cobra.
Sin misticismo y sin matemáticas: qué hace el modelo, por qué alucina, y cómo eso cambia tus decisiones de arquitectura.
Los tres pilares no son intercambiables. Cada uno responde una pregunta distinta, y usar el equivocado es el motivo de investigaciones que duran horas.
Por qué renombrar una columna rompe producción, y el patrón de cuatro pasos que convierte una migración en una tarea de martes por la tarde.
Cómo una dependencia secundaria lenta derriba el sistema entero en noventa segundos, y los cinco patrones que lo impiden.
Necesitas debitar en una cuenta y acreditar en otra, y están en bases de datos distintas. Los dos patrones que lo resuelven en la práctica, y qué evitar.
El CAP es el teorema más citado y peor enunciado de la computación distribuida. Este artículo corrige el enunciado y muestra el vocabulario que de verdad usas en el día a día.
El sharding es la decisión más irreversible de un sistema de datos. Esta es la guía para decidir si lo necesitas y, si lo necesitas, cómo elegir la clave.
Cómo funciona el índice por dentro, por qué el orden de las columnas lo decide todo, y cómo leer un plan de ejecución para saber qué hacer.
Poner caché es fácil. Lo difícil es convivir con las cuatro consecuencias que crea, y las cuatro tienen solución conocida.
La media de tu latencia está mintiendo. Los tres conceptos que convierten 'el sistema está lento' en una frase con número, endpoint y percentil.
Háblame
Sin formulario y sin lista de correo. Si no estás de acuerdo con algo que escribí, o quieres contarme cómo lo resolviste, la conversación es directa conmigo.