- Señala el problema de usar una arquitectura de sistema innecesariamente compleja a pesar de tener pocos usuarios reales
- Presenta casos en los que se combinan sin criterio diversas tecnologías como Redis, MongoDB, Kubernetes y microservicios
- Destaca situaciones en las que habría bastado con una única instancia de Postgres y una configuración de servidor sencilla
- Enfatiza que la complejidad no es una virtud y que solo se debe escalar cuando la necesidad esté demostrada
- Es un recordatorio para startups y equipos de desarrollo de que deben seguir principios de diseño simples acordes a su escala
Abuso innecesario del stack tecnológico
- Critica combinaciones de tecnologías elegidas al azar, como usar Redis y MongoDB al mismo tiempo
- Plantea preguntas como: “¿Por qué Redis está hablando con MongoDB?” y “¿Por qué están usando MongoDB?”
- Señala que se introdujo un sistema distribuido aunque el número real de usuarios era de apenas 12 (de los cuales 6 eran cuentas de prueba)
- Lo menciona como un caso de expansión excesiva, a pesar de que una sola instancia de Postgres habría sido suficiente
Exceso en la estructura de despliegue e infraestructura
- Configuración actual: 15 microservicios, 8 bases de datos, clústeres de Kubernetes en 3 entornos, 4 colas de mensajes, service mesh y un pipeline de CI/CD que tarda 2 horas
- Como configuración necesaria, propone algo cercano a un solo servidor, Postgres y Redis para caché
- Contrasta claramente el exceso de complejidad de infraestructura con las necesidades reales
Complejidad del sistema y capacidad de explicarlo
- Señala que hay un problema si para explicarle el sistema a un desarrollador junior hace falta un diagrama enredado como espagueti
- Resume el mensaje central con la frase: la complejidad no es una virtud
- Enfatiza que se debe empezar de forma simple y agregar complejidad solo cuando la necesidad esté demostrada
Lección principal
- La elección de tecnologías y el diseño del sistema deben simplificarse según la escala y el uso real
- Escalar sin criterio e incorporar un stack tecnológico excesivo perjudica la mantenibilidad y la eficiencia
- Es importante que las startups y los equipos pequeños mantengan una “simplicidad acorde a su escala”
1 comentarios
Opiniones de Hacker News
A veces esto parece simplemente procrastinación
Como no quieren hablar con clientes, inversionistas o el equipo legal, en vez de eso hacen el “trabajo divertido” desde la perspectiva de ingeniería
Por fuera parece productivo, pero en realidad no están avanzando
Si no te obligas a hacer cosas incómodas todos los días, te vas deteriorando poco a poco y después te topas con problemas grandes que podrías haber evitado
Esto no aplica solo al software, sino a la vida en general
Aprendí que para ganar dinero hay que hacer el trabajo con la prioridad correcta, no el más divertido
También me hace pensar si no será para satisfacer la obsesión por la arquitectura ideal de algún CTO o VPE desconectado de la realidad
Recuerdo haber tanteado el terreno en entrevistas de diseño de sistemas sobre monolítico vs. microservicios
Al final, la dirección que quieren las personas con poder suele ser clara, y oponerte a eso significa quemar capital político
Se ponen a alardear del stack técnico con cosas como “yo conecté ABC con XYZ”
También está el deseo de hacer que el CV se vea más impresionante
La verdad, la mayoría de los proyectos podrían hacerse perfectamente con tecnología de los 90, pero si metes términos como sistemas distribuidos se ve mucho más “cool”
Por culpa de la mala cultura de contratación de la industria, es como si a un chef no lo evaluaran por saber usar bien un cuchillo, sino por usar “una marca específica de cuchillo”
Por ejemplo, DuckDuckGo solo pide algoritmos y estructuras de datos, y solo aclara “por cierto, usamos Perl”
Stream ofrece un curso de 10 semanas a postulantes que no saben Go, y Jane Street tampoco exige experiencia en OCaml
La empresa donde trabajo, bevuta IT GmbH, también me permitió aprender Clojure después de entrar
Este enfoque es completamente distinto a anuncios anticuados como “10 años de experiencia en Ruby on Rails”
Fue porque quería probar cosas nuevas y compararlas
Al final, esa es la realidad de la industria: hablar de complejidad innecesaria para atender a unos cuantos cientos de usuarios
La frase “caché con Redis” se oye demasiado, pero en realidad muchas veces Postgres basta
Que el autor insista en usar Redis también da la impresión de que no pudo resistir su propio impulso al overengineering
A pequeña escala ni siquiera necesitas caché, y resulta más atractivo poner los datos temporales en un sistema aparte
Además, la abstracción de caché de la mayoría de los frameworks está diseñada pensando en Redis
Lo mejor es empezar con caché en memoria y agregar Redis cuando haga falta
Pero Redis/Valkey es demasiado. memcached es mucho más simple y práctico
Como no guarda estado al estilo Redis, evita malos patrones de diseño que dependen de la consistencia de la caché
La caché en la BD es lenta porque tiene que pasar por el sistema de archivos
Escribir consultas eficientes es un problema completamente distinto
Si vuelves a hacer rápido a Postgres, podrías quitar Redis, aunque normalmente se queda ahí
En una web app basada en AWS Lambda que manejaba 1000 solicitudes por segundo, Postgres sufría pero Redis iba sin problema
Por su simplicidad, en casos excepcionales sí vale la pena usarlo
Da risa que el autor hable de “simplicidad” y aun así haya hecho la página con Tailwind + framework de JS + bundler
Podría haberla hecho con HTML simple
Por eso presento MastroJS, un framework web simple que puedes construir tú mismo
En la práctica solo genera CSS para las clases utilitarias que usas
El tuit original viene de un tuit de Jeff Atwood de 2013
Yo ahora mismo también estoy pensando en una decisión parecida
Si el producto todavía no tiene validación de mercado, lo correcto es empezar pequeño y rápido para hacer un MVP que permita pivotear
En cambio, si necesitas mostrarles a inversionistas o a grandes empresas que sabes diseñar para escalar, entonces conviene elegir desde el inicio una estructura escalable
Si el modelo de negocio solo funciona al crecer tanto que una sola BD ya no dé abasto, entonces ir desde el principio por una arquitectura escalable sí da beneficios a largo plazo
Si trabajas en medio de una pesadilla de infraestructura, la simplicidad puede sonar a fantasía
Pero gran parte de la complejidad existe no tanto por razones técnicas, sino para resolver problemas organizacionales
La automatización de despliegues, la redundancia para tolerancia a fallos, los pipelines de CI, la gestión de secretos y la caché son mecanismos de seguridad para proteger al equipo
Ignorar eso es riesgoso cuando trabajas a nivel de equipo
SQLite también puede usarse perfectamente en producción, pero se ha extendido el prejuicio de que “solo sirve para pruebas”
A veces la configuración por defecto de un PaaS es innecesariamente compleja
Puedes empezar con un proceso de build basado en checklist, y cuando eso ya sea estable, expandirlo con automatización
Me gustaría ver casos reales donde microservicios sean de verdad necesarios en servicios que no sean nivel FAANG
A muchos les da miedo pensar, así que solo siguen el stack estándar
El problema es usar Kafka, Mongo o Redis sin cuestionarlo
En realidad, muchas veces es mejor implementar directamente solo lo que necesitas, y la capacidad de elegir el mínimo de componentes es una habilidad central de un ingeniero
Cosas como Kafka terminan siendo puro desperdicio de dinero
La idea de “agrega complejidad solo cuando haga falta” es correcta, pero hay casos en los que agregarla después es difícil
Si el diseño inicial sale mal, quizá necesites una reescritura completa
Por eso, en la práctica, a veces hace falta un punto medio como una configuración simple de k8s
Hace poco tuve una experiencia parecida en una entrevista
Durante 10 años me he enfocado en conseguir PMF (Product-Market Fit), no en obsesionarme con escalar desde el día uno
Si el producto encaja con el mercado, los problemas de escalabilidad se pueden resolver con dinero
Pero en la entrevista me preguntaron cómo escalar un servicio de Django a 10 millones de solicitudes al día
Respondí “subiendo las especificaciones del servidor”, y no pareció dejarles muy satisfechos