La industria entera escribe sobre cómo escalar a millones de usuarios por segundo. Pero la mayoría de los sistemas que efectivamente corren en producción no son ese sistema. Son aplicaciones chicas, usadas por cientos o miles de personas, que aún así son críticas: porque manejan dinero, salud, decisiones legales, logística, datos sensibles, o porque caerse cinco horas un martes le cuesta a alguien mucho más que el orgullo.

Esos sistemas tienen un problema cultural antes que técnico. Sus equipos copian patrones de empresas que resolvieron problemas distintos a los suyos. Microservicios cuando un monolito modular alcanzaba. Kubernetes cuando systemd era suficiente. Event sourcing cuando una transacción ACID resolvía el caso. Eventual consistency cuando el negocio exigía lo contrario. El resultado es over-engineering caro, frágil, y operado por equipos chicos que no pueden mantenerlo.

Esta charla propone una distinción que suena obvia pero que en la práctica casi nadie respeta: escala no es lo mismo que criticidad. Hay sistemas que tienen que aguantar mucha carga. Hay sistemas que tienen que ser confiables, recuperables, mantenibles y auditables. A veces coinciden, pero la mayor parte del tiempo no. Y diseñar para el problema equivocado es la fuente más común de complejidad innecesaria que vi en veinte años.

Voy a recorrer, con código Python real, los anti-patrones más comunes y los patrones que sí funcionan: cuándo un monolito modular gana, cuándo Postgres alcanza para todo, cuándo arq o dramatiq reemplazan a Kafka, cuándo backups bien hechos importan más que alta disponibilidad sofisticada. Y un framework mental simple para decidir, en cada componente nuevo, si la complejidad se justifica o se asume sin pensar.

Pensada para tech leads, arquitectos, senior developers y engineering managers que diseñan sistemas Python reales en equipos chicos.