Feliz Miércoles, fellow dev. 👋

Imagina que te hacen una pregunta aparentemente sencilla:

“Diseña WhatsApp.”

Tienes aproximadamente 45 minutos para demostrar tu seniority, tomar decisiones de arquitectura, identificar bottlenecks y explicar claramente tu razonamiento.

Y el reloj ya está corriendo.

Este es uno de los motivos por los que considero que nunca deberías improvisar una entrevista de Systems Design.

Necesitas un framework.

No para memorizar respuestas.

Sino para tener una estructura mental que te permita concentrarte en lo realmente importante mientras estás bajo presión.

1️⃣ No empieces diseñando: empieza preguntando

Uno de los errores más peligrosos en Systems Design es escuchar el problema y empezar inmediatamente a dibujar cajas.

Frontend.

Load Balancer.

Backend.

Database.

Redis.

Para aquí. Todavía no sabes qué estás construyendo.

Estas entrevistas son deliberadamente ambiguas, porque el entrevistador también quiere evaluar tu capacidad para descubrir requisitos.

Por eso tus primeros minutos deberían estar dedicados a entender el scope.

Empieza por los functional requirements:

• ¿Qué tiene que poder hacer el usuario?
• ¿Quién utilizará el sistema?
• ¿Qué funcionalidades debemos priorizar?

Porque “diseña una aplicación de mensajería” puede significar cosas completamente diferentes.

• WhatsApp está orientado principalmente a conversaciones privadas y grupos.
• Slack, a comunicación dentro de organizaciones.
• Discord, a comunidades.

Las tres permiten enviar mensajes.

Pero sus requisitos y desafíos arquitectónicos son diferentes.

Después pasa a los non-functional requirements.

Escalabilidad.

Latencia.

Disponibilidad.

Rendimiento.

No es lo mismo diseñar un Twitter para 1.000 usuarios que para cientos de millones.

Y cuanto más senior sea el puesto, más importante será esta conversación.

2️⃣ Los números te ayudan a diseñar

Antes de decidir tecnologías, necesitas entender aproximadamente la escala del problema.

Aquí entran las famosas back-of-the-envelope calculations.

No necesitas calcular todo con precisión matemática.

Necesitas conocer el orden de magnitud.

• ¿Cuántos usuarios activos esperamos?
• ¿Cuántas requests por segundo?
• ¿Cuántas escrituras?
• ¿Cuánto almacenamiento necesitaremos?
• ¿Cuánto tráfico puede recibir el sistema?

Estos números empiezan a descubrir dónde aparecerán tus bottlenecks.

Y eso cambia completamente la conversación.

Porque decir:

“Voy a utilizar esta base de datos porque escala mucho”

no demuestra demasiado.

Pero decir:

“Esperamos aproximadamente X escrituras por segundo, por lo que una única instancia probablemente se convierta en un bottleneck y necesitamos plantearnos…”

ya demuestra razonamiento de ingeniería.

3️⃣ Diseña de arriba hacia abajo ("Top Down")

Una vez entendido el problema, empieza el High-Level Design.

Mi recomendación es seguir un enfoque top-down.

Primero define las APIs.

• ¿Qué endpoints necesita tu sistema?
• ¿Qué inputs reciben?
• ¿Qué responses devuelven?
• ¿Necesitas REST?
• ¿Existe comunicación bidireccional que pueda justificar WebSockets?

Las APIs establecen el contrato entre los clientes y tu backend, por lo que también te ayudan a comprobar que realmente estás cubriendo los functional requirements anteriores.

Después empieza tu arquitectura.

• API Gateway o Load Balancer.
• Servicios.
• Persistencia.
• Caché cuando tenga sentido.
• Colas cuando sean necesarias.
• Almacenamiento.

Pero aquí existe otra trampa:

NO hagas deep dive demasiado pronto.

Si empiezas a discutir durante 10 minutos cómo vas a hacer sharding antes de terminar el diseño general, probablemente vas a quedarte sin tiempo.

Primero termina el mapa.

Después profundiza.

4️⃣ Aquí es donde realmente demuestras tu seniority

Una vez tienes el High-Level Design, empieza para mí la parte más interesante de la entrevista:

El deep dive.

Ahora sí.

Busca los puntos donde tu arquitectura puede romperse.

Imagina, por ejemplo, que estás diseñando un sistema similar a Google Maps y necesitas gestionar un millón de actualizaciones de ubicación por segundo.

Ya tienes un problema concreto.

Entonces utiliza esta estructura:

1. Define el bottleneck.

Una única base de datos probablemente no pueda absorber ese volumen de escrituras.

2. Propón alternativas.

Podrías reducir la frecuencia con la que los clientes envían actualizaciones.

O utilizar una arquitectura de almacenamiento preparada para un write throughput mucho mayor.

3. Explica los trade-offs.

• ¿Qué ganas?
• ¿Qué sacrificas?
• ¿Cómo afecta cada alternativa a latencia, consistencia, complejidad o coste?

4. Toma una decisión.

Esto último es importantísimo.

Un Senior Engineer no debería limitarse a decir:

“Podemos hacer A o B.”

Tiene que ser capaz de decir:

“Para estos requisitos escogería B por estas razones.”

Systems Design no consiste en conocer 200 tecnologías.

Consiste en tomar decisiones justificadas bajo restricciones.

💡 Mi conclusión

Hay una idea que quiero que recuerdes para tu próxima entrevista:

Systems Design no es una prueba de dibujo.

Es una prueba de razonamiento.

Tu entrevistador no necesita que dibujes la arquitectura más sofisticada posible.

Quiere entender cómo piensas.

Cómo transformas un problema ambiguo en requisitos.

Cómo utilizas números para estimar escala.

Cómo construyes una arquitectura que satisface esos requisitos.

Cómo detectas bottlenecks.

Cómo analizas trade-offs.

Y finalmente, cómo tomas decisiones.

Por eso te recomiendo entrenar siempre utilizando una estructura:

Scope → High-Level Design → Deep Dive → Cierre.

No memorices cómo diseñar Twitter, Uber, Netflix o WhatsApp.

Aprende un proceso que puedas aplicar cuando mañana te pidan diseñar un sistema que nunca hayas visto antes.

Esa es la skill que realmente quieres desarrollar.

¿Cómo puedo ayudarte?

Si quieres formarte conmigo 1-1, DevAccelerator™ está cerrado, pero te puedes unir a nuestra lista de espera.​

-Patri