“How would you design a URL shortener like Bit.ly?”
Empieza siempre por los requisitos antes de dibujar nada: crear códigos cortos, redirigir rápido y aguantar mucha lectura. Luego hash o contador base-62 para el código, base de datos para el mapeo y caché delante para los enlaces calientes. Como las redirecciones son read-heavy, caché y réplicas de lectura son lo que importa. Cierra pidiendo dirección.
Let me start with the requirements: we need to create short codes, redirect quickly, and handle high read traffic. I'd use a hash or a base-62 counter to generate the code, store the mapping in a database, and put a cache in front for the hot links. For scale, redirects are read-heavy, so caching and read replicas matter most. Do you want me to go deeper on the data model or the scaling side?
Nivel B1-B2: pensada para que la adaptes a tu experiencia, no para memorizarla palabra por palabra. Cambia el stack, los años y el contexto por los tuyos.
El system design en inglés castiga doble: tienes que razonar sobre arquitectura y narrarlo a la vez en tu segundo idioma. El entrevistador evalúa si acotas el problema antes de resolverlo y si colaboras o monologas. El acortador de URLs es el ejercicio de entrada más frecuente porque es simple de enunciar y escala en cualquier dirección.
En resumen: En system design, empieza siempre por los requisitos y piensa en voz alta. Cerrar pidiendo dirección ('go deeper on X or Y?') demuestra colaboración.
Esta pregunta se responde en voz alta y bajo presión. En DevLingo la ensayas con un tutor IA que hace de entrevistador y te corrige la frase concreta que dijiste mal, no un listado genérico de errores.
Ensayar esta pregunta gratisTodas las preguntas de entrevista·Glosario de inglés técnico