Oye, te voy a contar algo que me pasó.

Había una época donde cada vez que veía un video o blog que decía "System Design", lo saltaba inmediatamente. Pensaba: "Eso es para ingenieros seniors, para arquitectos... no es para mí".

Qué equivocado estaba.

Porque llegó el día en una entrevista donde me preguntaron: "¿Podrías diseñar una aplicación como Uber?" Y me congelé.

Hablé de APIs REST, mencioné MySQL... y después... silencio incómodo. Ni idea de cómo manejar escala, cero conocimiento de colas, ni siquiera sabía cómo almacenar ubicación en tiempo real.

Ese día tomé la decisión: esto no me volvería a pasar. Y aquí te cuento cómo pasé de estar totalmente perdido a poder discutir arquitecturas con confianza.

1. Primero acepté que no sabía nada (y estaba bien)
Al principio el diseño de sistemas da miedo. La gente suelta términos como "sharding", "CQRS", "load balancer"... y tú ahí como  .

Pero luego entendí algo importante: todos nos sentimos perdidos al principio.

El diseño de sistemas no es un tema que "aprendes" en una semana. Es entender:

• Cómo fluyen los datos

• Cómo se comunican los servicios

• Cómo los sistemas aguantan tráfico pesado

• Cómo hacer todo rápido y confiable

Cuando acepté que esto tomaría tiempo, me quitó presión. Dejé de buscar perfección y me enfoqué en pequeños logros.

2. Rompí el "System Design" en temas más pequeños
Me di cuenta que no era una materia gigante, sino bloques conectados. Hice mi propio mapa mental:

Lo básico:

• Qué pasa cuando pones una URL

• DNS, Load Balancer, CDN

• TCP vs UDP, HTTP vs HTTPS

Hasta esto básico me sorprendió. ¿Sabías que el DNS es como la guía telefónica de internet?

Datos y almacenamiento:

• SQL vs NoSQL

• Indexado, replicación, sharding

• Cuándo usar MongoDB vs PostgreSQL

Esto lo aprendí a las malas: en un proyecto elegimos Mongo para datos transaccionales... mala idea.

Escalado:

• Horizontal vs vertical

• Caché (Redis, Memcached)

• Balanceo de carga

Esta parte me encantó porque sentí que podía diseñar para millones de usuarios.

Patrones:

• Monolito vs Microservicios

• Arquitectura orientada a eventos (Event-Driven)

• Colas de mensajes (Pub/Sub, message Queues [kafka, RabbitMQ])

Entendí por qué Netflix usa microservicios: no es moda, es necesidad.

3. Empecé a ver gente pensar, no solo enseñar
Cambié los tutoriales por entrevistas de práctica. Y eso lo cambió TODO.

Cuando ves a alguien pensar en voz alta, equivocarse, corregirse... aprendes a PENSAR, no a copiar.

Canales que me ayudaron:

• Gaurav Sen (explica desde cero)

• Exponent (entrevistas reales)

• ByteByteGo (visual, como historia) -> Recomendado

Aprendí a:

• Hacer preguntas para clarificar

• Definir qué necesita el sistema

• Diseñar APIs, elegir bases de datos

• Hablar de trade-offs, no solo elecciones

4. Me puse a dibujar (aunque fuera feo, muchas veces se reían de mis garabatos)
Esto fue sorprendente: dibujar flujos aunque fuera en papel hizo que todo hiciera CLIC.

No soy artista. Pero esbozar un flujo desde cliente → balanceador de carga → servidores de aplicaciones → base de datos me hizo entenderlo con mucha claridad.

Cuando dibujaba:

• El flujo se sentía real

• Veía cuellos de botella

• Entendía dónde poner caché o colas

Hasta hoy, cuando me trabo, agarro lápiz y papel.

5. Practiqué con problemas reales
Cuando me sentí cómodo con lo básico, dejé de ver y empecé a DISEÑAR.

Mi método que estado aplicando desde entonces:

• Elegía sistemas reales: WhatsApp, YouTube, Instagram

• Definía qué debería hacer (requisitos funcionales)

• Agregaba requisitos de escala (requisitos no funcionales)

• Hacía estimados aproximados (usuarios, QPS, tamaño de la base de datos)

• Diseñaba arquitectura

• Profundizaba en bases de datos, APIs, escalado, manejo de fallos y casos extremos

Hacía un diseño por semana cuando podia, ya que el trabajo no me daba mucho tiempo; habian veces que era cada 15 días, siempre considerando múltiples soluciones.

Nota: Porque en las entrevistas reales (y en los trabajos reales), rara vez hay una respuesta perfecta. Se trata de justificar por qué elegiste X en lugar de Y.

6. Lo apliqué en el trabajo
La teoría sin práctica no sirve.

En mi trabajo teníamos un servicio con mucho tráfico. Ahí empecé a aplicar lo aprendido:

• Propuse dividir un monolito en servicios

• Usé colas para comunicación async (asincrónica)

• Introduje reintentos y manejo de errores

• Debatí Kafka vs gRPC (basando en latencia y control)

No fue perfecto, pero me dio confianza: el diseño de sistemas SIRVE en la vida real, en pocas palabras una habilidad real y valiosa que ayuda a tu equipo y a tu producto..

7. Empecé a explicar a otros
Este fue el nivel final.

Cuando explicas algo, ya sea a un joven, a un pasante o en un blog o tus hijos o tus sobrinos descubres los huecos en tu entendimiento.

Así que:

• Mentoré a juniors

• Di pequeñas sesiones para explicar sobre caching, bases de datos y colas

• Escribí artículos (si tiene muchos diagramas mejor pero que sean claro, ojo con eso)

• Preparé a otros para entrevistas

Si puedes explicarlo simple, es porque lo entiendes de verdad.

Mi consejo honesto:
Si estás empezando o ya fallaste en una entrevista, quiero decirte:

El diseño de sistemas no es magia.
No necesitas 10 años de experiencia.
No tienes que memorizar diagramas.

Solo necesitas:

• Empezar con lo básico

• Pensar en casos reales

• Practicar regularmente

• Preguntar "por qué" detrás de cada decisión

• Y poco a poco ir mejorando, no pares de aprender

Aunque le dediques 30 minutos diarios, en 3 meses verás la diferencia.

Para cerrar:
No se trata de tener todas las respuestas, sino de cómo abordas los problemas.

Cuando puedes explicar:

• ¿Cuál es la escala?

• ¿Dónde están los cuellos de botella?

• ¿Qué trade-offs (ventajas y desventajas) tiene cada decisión?

• ¿Qué pasa si algo falla?

Eso es lo que te hace un buen ingeniero. No los diagramas que memorizaste.

Así que sigue adelante. Empieza con "¿cómo funciona una URL?" y termina diseñando Instagram.

Te sorprenderás de lo lejos que llegas... recuerda siempre un sistema a la vez.