Preparar una entrevista de system design (diseño de sistemas)
La entrevista de system design es la que más intimida porque no tiene una respuesta única: te dan un enunciado vago («diseñá un acortador de URLs», «diseñá el feed de una red social») y evalúan cómo pensás, no si llegás a «la» solución. Lo que hunde a la mayoría no es no saber, es arrancar a dibujar cajas sin haber acordado qué se está construyendo.
El método que funciona es siempre el mismo: aclarar requisitos (funcionales y no funcionales), estimar la escala (lecturas vs escrituras, QPS, tamaño de datos), proponer un diseño de alto nivel, y recién entonces profundizar en los componentes donde está el trade-off interesante —caché, base de datos, colas, rate limiting—. El entrevistador quiere verte justificar cada decisión y reconocer qué resignás con cada una.
Abajo tenés una tarjeta y una pregunta reales, del mismo tipo que vas a practicar adentro. Ninguna es de memoria: se responden razonando el trade-off.
Probá una muestra
Tu API pública empieza a recibir picos de tráfico de unos pocos clientes que la saturan. Querés proteger el servicio sin castigar al resto. ¿Qué implementás primero?
Qué cubre alfront de este tema
- El método para diseñar en voz alta: requisitos, estimación de escala y diseño de alto nivel antes de profundizar
- Caching: qué cachear, invalidación y el costo real de los datos stale
- Rate limiting y protección del servicio: aislar clientes, token bucket
- Trade-offs de escala (consistencia, disponibilidad, latencia) razonados, no recitados
Empezá a practicar hoy
Adentro tenés la práctica completa: repaso espaciado, la ficha de cada tema y la entrevista por voz para ensayar bajo presión.
Preguntas frecuentes
¿Qué evalúan de verdad en una entrevista de system design?
Cómo pensás bajo ambigüedad: si aclarás requisitos antes de diseñar, si estimás la escala, si justificás cada decisión y reconocés qué resignás. No buscan «la» solución correcta; buscan un razonamiento ordenado y consciente de los trade-offs.
¿Por dónde empiezo a responder un enunciado de system design?
Por los requisitos: qué tiene que hacer el sistema (funcionales) y con qué restricciones de escala, latencia y disponibilidad (no funcionales). Después estimás magnitudes (lecturas vs escrituras, QPS) y recién ahí dibujás. Arrancar por las cajas sin acordar el problema es el error más común.
¿Necesito haber diseñado sistemas grandes en el trabajo?
Ayuda, pero no es requisito: lo que se entrena es el método y el vocabulario de trade-offs. Practicando preguntas reales con su trampa, y explicando tu diseño en voz alta, llegás preparado aunque tu experiencia sea acotada.
¿Cómo practico esto en alfront?
Con la cola de repaso espaciado sobre las tarjetas de arquitectura, caching y sistemas distribuidos —cada una con su trampa— y ensayando el razonamiento en voz alta en la entrevista por voz. Empezás con 7 días de prueba con todo incluido.
Otras guías
Según la oferta
Armar un plan de estudio para una entrevista técnica según la oferta
Empresas tech de LATAM
Preparar una entrevista técnica en una empresa tech de LATAM
Entrevista junior
Preparar tu primera entrevista técnica sin experiencia previa
Preguntas de comportamiento
Preparar las preguntas de comportamiento de una entrevista técnica
SQL y bases de datos
Preparar una entrevista de SQL y bases de datos
APIs REST y autenticación
Preparar una entrevista de APIs REST y autenticación
Colas y mensajería
Preparar una entrevista de backend asíncrono: colas y mensajería
Docker y contenedores
Preparar una entrevista de Docker y contenedores
Examen AWS SAA-C03
Preparar el examen AWS Solutions Architect Associate (SAA-C03)
Sistemas distribuidos
Preparar una entrevista de sistemas distribuidos
No quedarte en blanco
Qué hacer para no quedarte en blanco en una entrevista técnica