BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.com//pycones-2026//talk//PZSXXW
BEGIN:VTIMEZONE
TZID:Europe/Madrid
BEGIN:STANDARD
DTSTART:20251107T000000
TZNAME:CET
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20260329T030000
RDATE:20270328T030000
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20261025T030000
RDATE:20271031T030000
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Diseñando arquitecturas reales. Cuando tu sistema no necesita esc
 alar a un millón de usuarios. - Juan Rodriguez Monti
DTSTART;TZID=Europe/Madrid:20261107T105000
DTEND;TZID=Europe/Madrid:20261107T113000
DTSTAMP:20260726T231356Z
UID:pretalx-pycones-2026-PZSXXW@pretalx.com
DESCRIPTION:La industria entera escribe sobre cómo escalar a millones de 
 usuarios por segundo. Pero la mayoría de los sistemas que efectivamente c
 orren 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 mane
 jan 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.\n\nEsos sistemas tienen un problema cultural antes que técnico.
  Sus equipos copian patrones de empresas que resolvieron problemas distint
 os a los suyos. Microservicios cuando un monolito modular alcanzaba. Kuber
 netes cuando systemd era suficiente. Event sourcing cuando una transacció
 n ACID resolvía el caso. Eventual consistency cuando el negocio exigía l
 o contrario. El resultado es over-engineering caro\, frágil\, y operado p
 or equipos chicos que no pueden mantenerlo.\n\nEsta charla propone una dis
 tinción que suena obvia pero que en la práctica casi nadie respeta: esca
 la no es lo mismo que criticidad. Hay sistemas que tienen que aguantar muc
 ha carga. Hay sistemas que tienen que ser confiables\, recuperables\, mant
 enibles y auditables. A veces coinciden\, pero la mayor parte del tiempo n
 o. Y diseñar para el problema equivocado es la fuente más común de comp
 lejidad innecesaria que vi en veinte años.\n\nVoy a recorrer\, con códig
 o Python real\, los anti-patrones más comunes y los patrones que sí func
 ionan: cuándo un monolito modular gana\, cuándo Postgres alcanza para to
 do\, cuándo arq o dramatiq reemplazan a Kafka\, cuándo backups bien hech
 os importan más que alta disponibilidad sofisticada. Y un framework menta
 l simple para decidir\, en cada componente nuevo\, si la complejidad se ju
 stifica o se asume sin pensar.\n\nPensada para tech leads\, arquitectos\, 
 senior developers y engineering managers que diseñan sistemas Python real
 es en equipos chicos.
LOCATION:Track 04 - OLX
URL:https://pretalx.com/pycones-2026/talk/PZSXXW/
END:VEVENT
END:VCALENDAR
