Himanshu Singour. 7 de agosto de 2025. MEDIUM

– El viaje honesto de la confusión total a la claridad

Déjame ser brutalmente honesto contigo.

Hubo una época en la que me saltaba todos los vídeos o blogs que hablaban de «Diseño de Sistemas».
Pensaba: «Esto es para ingenieros y arquitectos experimentados, no para mí».

Me equivoqué.

Porque un día, en una entrevista, me preguntaron:
“¿Puedes diseñar una aplicación de viajes compartidos como Uber?”
Y me quedé congelado.

Hablé de las API REST.
Mencioné MySQL.
Y luego… silencio.
Ni idea de cómo gestionar la escalabilidad, ni de colas, ni siquiera de cómo almacenar la ubicación en tiempo real.

Ese día decidí que esto no volvería a ocurrir.
Así fue como pasé de estar totalmente perdido a hablar de arquitectura con confianza en las entrevistas, e incluso a proponer mejores diseños en el trabajo.

1. Primero, acepté que no sabía nada y eso estaba bien.

El diseño de sistemas es intimidante al principio.
La gente usa términos como «fragmentación», «CQRS», «balanceador de carga», «consistencia eventual»…

Al principio, me sentí un poco tonto. Pero luego me di cuenta de que
todos nos sentimos perdidos al principio.

El diseño de sistemas no es un tema único. No es un capítulo que se pueda completar en una semana.
Es una combinación de:

• Cómo fluyen los datos
• Cómo se comunican los servicios entre sí
• Cómo sobreviven los sistemas bajo un tráfico enorme
• ¿Y cómo hacer que las cosas sean tolerantes a fallos, rápidas y confiables?

Una vez que acepté que esto llevaría tiempo, me sentí más ligero.
Dejé de perseguir la perfección y me concentré en los pequeños logros.

2. Dividí el «Diseño de sistemas» en minitemas

El diseño de sistemas no es un tema extenso, sino un conjunto de componentes interconectados.
Así que hice un mapa:

a) Los conceptos básicos

• ¿Qué sucede cuando escribes una URL en el navegador?
• ¿Qué es DNS, Load Balancer y CDN?
• TCP frente a UDP, HTTP frente a HTTPS

Incluso estos conceptos básicos fueron reveladores.
¿Sabías que el DNS es como una guía telefónica de internet? ¿Y que las CDN son la razón por la que YouTube carga tan rápido?

b) Datos y almacenamiento

• SQL frente a NoSQL
• Indexación, replicación y fragmentación
• Cuándo elegir MongoDB vs PostgreSQL

Aprendí esto a las malas. En un proyecto, elegimos Mongo para los datos transaccionales. Después, nos arrepentimos.

c) Técnicas de escalamiento

• Escala horizontal vs. vertical
• Almacenamiento en caché (Redis, Memcached)
• Equilibrio de carga (Round-robin, Hashing de IP)

Me encantó esta parte. Me hizo sentir que por fin podía diseñar algo para millones de usuarios, aunque solo fuera en papel.

d) Patrones de arquitectura

• Monolito vs. microservicios
• Arquitectura basada en eventos
• Pub/Sub, colas de mensajes (Kafka, RabbitMQ)

This made me understand why companies like Netflix use microservices not just because it’s tre

3. Vi a gente real pensar, no solo enseñar

En lugar de ver vídeos tipo tutorial, comencé a ver entrevistas simuladas.

Y créeme, eso lo cambió todo.

Porque cuando alguien piensa en voz alta, se equivoca, se retracta y justifica sus decisiones aprende a pensar , no sólo a copiar .

Canales que realmente ayudaron:

• Gaurav Sen lo explica desde cero
• Entrevistas simuladas de Exponent con candidatos reales
• El enfoque visual y narrativo de ByteByteGo

Aprendí a:

• Haga las preguntas aclaratorias adecuadas
• Definir requisitos funcionales y no funcionales
• Recorrido por el diseño de API, opciones de base de datos y lógica de escalado
• Hable siempre de compensaciones , no sólo de elecciones.

4. Empecé a dibujar aunque fuera solo en papel

¿Algo sorprendente que me ayudó?
Dibujar.

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

Cuando dibujé:

• El flujo de solicitudes se sintió real.
• Vi dónde podrían producirse cuellos de botella.
• Entendí dónde colocar un caché, cuándo usar una cola.

Incluso hoy, cuando me quedo atascado, tomo lápiz y papel.
Ese boceto a menudo me da la claridad que la lectura nunca me dio.

5. Practiqué con problemas reales de diseño de sistemas.

Una vez que tuve confianza en los conceptos básicos, dejé de mirar y comencé a diseñar.

Así es como lo practiqué:

• Elija un sistema del mundo real: WhatsApp, YouTube, Zomato, Instagram
• Escriba primero los requisitos funcionales (lo que debe hacer el sistema)
• Luego agregue requisitos no funcionales (escala, disponibilidad, latencia)
• Hacer una estimación aproximada (usuarios, QPS, tamaño de la base de datos)
• Diseñar una arquitectura de alto nivel

Profundizar en:

• Esquema de base de datos
• API
• Estrategias de escalamiento
• Manejo de fallos
• Casos extremos

Escribía un diseño por semana.
Y no solo una solución, sino múltiples posibilidades .

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 es inútil si no la aplicas.

En el trabajo, trabajaba en un servicio de alto tráfico para la generación de EMI.
Contaba con eventos de Kafka, API REST y transacciones complejas.

Aquí es donde comencé a aplicar los principios de diseño:

• Propuse dividir un monolito en servicios.
• Colas utilizadas para comunicación asincrónica
• Se introdujeron reintentos y colas de mensajes muertos
• E incluso se debatió Kafka vs gRPC (basado en latencia y control)

No fue perfecto. Pero me dio la confianza de que el diseño de sistemas no es solo cuestión de entrevistas, sino una habilidad real y valiosa que ayuda a tu equipo y a tu producto.

7. Empecé a explicarles a los demás

Este fue el nivel final.

Cuando explicas algo, ya sea a un junior, a un pasante o en un blog, detectas las lagunas en tu propia comprensión.

Así que yo:

• Mentoría a jóvenes durante la incorporación
• Realizó pequeñas sesiones para explicar el almacenamiento en caché, el diseño de bases de datos y las colas.
• Escribió artículos con diagramas.
• Comenzó a preparar a los jóvenes para las entrevistas de diseño.

Cada vez que explicaba algo, me daba cuenta:
si puedo enseñarlo de forma sencilla, en realidad lo entiendo bien.

Mi consejo honesto para ti

Si estás empezando hoy, o si has fracasado en tu primera entrevista de diseño quiero decirte esto:

El diseño de sistemas no es magia.No necesitas 10 años de experiencia.No necesitas memorizar los diagramas de Gaurav Sen.

Sólo necesitas:

• Empezar con lo básico
• Piense en casos de uso del mundo real
• Construir una estructura
• Practica semanalmente
• Pregúntate “por qué” detrás de cada elección
• Y poco a poco ir mejorando

Incluso si dedicas 30 minutos diarios durante 3 meses, verás la diferencia.

Reflexión final: No se trata de respuestas, sino de enfoque

En el diseño de sistemas, a menudo te sentirás inseguro. Es normal.
Lo importante es cómo abordas un problema.

Cuando explicas:

• ¿Cual es la escala?
• ¿Cuál es el cuello de botella?
• ¿Cuáles son las ventajas y desventajas de esta base de datos frente a aquella?
• ¿Qué pasa si este servicio falla?

Eso es lo que te hace un buen ingeniero.
No la cantidad de diagramas memorizados.

Así que sigue.
Empieza con «¿Cómo funciona una URL?» y termina con el diseño de Instagram.

Te sorprenderá lo lejos que has llegado con cada sistema.

Si llegaste hasta aquí, gracias ❤️

Estoy compartiendo más aprendizajes similares desde el backend real en mi viaje.

– Himanshu Singor