30 Preguntas de System Design de Entrevistas FAANG (Con Pistas de Respuesta)
Algo que nadie te cuenta sobre las entrevistas de system design en las FAANG: las preguntas se repiten. No al pie de la letra, pero los patrones subyacentes rotan en un conjunto sorprendentemente reducido. El “Disena YouTube” de Google y el “Disena Instagram Reels” de Meta son, a nivel arquitectonico, el mismo problema con distinto disfraz.
Lo descubri a la fuerza — despues de preparar unas veinte preguntas que parecian todas unicas, para darme cuenta de que dibujaba sistematicamente las mismas tres o cuatro arquitecturas base. Los detalles cambian. La estructura, no. El dia que empece a ver los patrones en vez de los nombres de productos, todo encajo.
Esta lista es el resultado de esa revelacion. Treinta preguntas, agrupadas por dificultad, cada una con una breve explicacion de por que se plantea y una pista de enfoque para arrancar. No son soluciones completas — si buscas un proceso estructurado para resolverlas, consulta el framework URDGE para entrevistas de system design. Esta lista es tu banco de problemas.
Principiante (Preguntas 1-10)
Este es el nivel de calentamiento. La mayoria de candidatos de nivel medio se encontrara con al menos una de estas. Prueban conceptos fundamentales — patrones de lectura/escritura, cache, escalado basico, diseno de API. No dejes que la palabra “principiante” te engane; una respuesta superficial aqui tambien lleva al rechazo.
1. Disenar un acortador de URLs (tipo Bitly)
Por que se pregunta: Es el “Hello World” del system design. Prueba tu comprension del hashing, almacenamiento clave-valor, patrones de acceso intensivos en lectura y diseno basico de API. Practicamente todas las FAANG han usado alguna variante de esta pregunta.
Conceptos clave: Estrategias de hashing (base62 vs truncado MD5), almacenes clave-valor, cache read-through, redirecciones 301 vs 302, manejo de colisiones.
Pista de enfoque: Empieza por el contrato de API (crear URL corta, redirigir). Estima la escala — escrituras por segundo, ratio lectura/escritura. Un almacen clave-valor como DynamoDB encaja naturalmente. Anade cache Redis para URLs populares, ya que el trafico sigue una distribucion de Pareto. Lo interesante es tu estrategia de generacion de claves — discute los trade-offs entre IDs autoincrementales con codificacion base62 versus hashing.
2. Disenar una herramienta de pegado (tipo Pastebin)
Por que se pregunta: Es un acortador de URLs con un giro — ahora almacenas contenido, no solo mappings. Prueba tu razonamiento sobre almacenamiento de objetos, limites de tamano y expiracion por TTL.
Conceptos clave: Almacenamiento de objetos (S3), separacion metadatos/contenido, expiracion TTL, control de acceso (pegados publicos vs privados), rate limiting.
Pista de enfoque: Separa los metadatos (titulo, expiracion, autor) en una base de datos del contenido real en almacenamiento de objetos. Genera claves unicas de manera similar a un acortador de URLs. Anade un servicio de limpieza que expire los pegados antiguos. El detalle que la mayoria de candidatos olvida: que pasa cuando un pegado se vuelve viral? Cache CDN para pegados publicos resuelve eso.
3. Disenar un limitador de velocidad (rate limiter)
Por que se pregunta: Es enganosamente simple y prueba tu comprension de la coordinacion distribuida. Cualquiera puede describir el token bucket en teoria; el desafio es hacerlo funcionar a traves de multiples servidores de aplicacion.
Conceptos clave: Algoritmos token bucket vs ventana deslizante, Redis para estado distribuido, condiciones de carrera con peticiones concurrentes, limites por usuario vs por IP vs por endpoint.
Pista de enfoque: Elige un algoritmo especifico — token bucket es el mas facil de explicar. Usa Redis con operaciones atomicas (INCR + EXPIRE) para almacenar contadores. Discute donde vive el limitador (API gateway vs middleware). La profundidad real viene de los casos limite: que pasa con el rate limiting distribuido a traves de multiples data centers? Como manejas las rafagas de manera elegante?
4. Disenar un almacen clave-valor
Por que se pregunta: Esta pregunta explora tu conocimiento de los mecanismos internos de bases de datos. Es comun en Google y Amazon, donde se espera que entiendas lo que pasa bajo el capo, no solo que uses servicios gestionados.
Conceptos clave: Arboles LSM vs B-trees, write-ahead logs, compactacion, replicacion (lider-seguidor vs sin lider), hashing consistente para particionamiento, trade-offs del teorema CAP.
Pista de enfoque: Clarifica los requisitos primero — esta optimizado para lectura o escritura? Para escritura intensiva, usa un enfoque LSM tree (memtable + SSTables + compactacion). Para escenarios distribuidos, usa hashing consistente para particionar datos entre nodos. Discute la estrategia de replicacion y que pasa durante una caida de nodo. La conversacion sobre trade-offs (consistencia vs disponibilidad) es donde se ganan los puntos.
5. Disenar un sistema de notificaciones
Por que se pregunta: Toca multiples canales de entrega (push, SMS, email) y prueba tu capacidad para disenar sistemas asincronos fiables que degraden con gracia.
Conceptos clave: Colas de mensajes, patrones de fan-out, garantias de entrega (al-menos-una-vez vs exactamente-una-vez), gestion de preferencias de usuario, rate limiting por canal, retry con backoff exponencial.
Pista de enfoque: Empieza con un servicio de notificaciones que acepta peticiones y las enruta a workers especificos por canal a traves de colas de mensajes (una cola por canal). Usa un almacen de preferencias para que los usuarios controlen lo que reciben. La decision de diseno clave es la fiabilidad: como garantizas que una notificacion se entregue al menos una vez sin bombardear a los usuarios? Claves de idempotencia y un registro de entrega resuelven esto.
6. Disenar un generador de IDs unicos (distribuido)
Por que se pregunta: Aparentemente trivial, pero revela si entiendes el coste de coordinacion en sistemas distribuidos. El autoincremento no funciona a traves de multiples servidores, y esta pregunta explora por que.
Conceptos clave: IDs Snowflake (timestamp + ID de maquina + secuencia), trade-offs de UUID (almacenamiento, ordenabilidad), problemas de sincronizacion de reloj, rangos de IDs preasignados.
Pista de enfoque: El enfoque Snowflake de Twitter es la respuesta estandar: IDs de 64 bits compuestos de timestamp (41 bits), ID de maquina (10 bits) y numero de secuencia (12 bits). Esto da IDs unicos y ordenables sin coordinacion entre servidores. Discute el problema de deriva de reloj y como NTP ayuda pero no lo resuelve completamente. Compara con UUIDs — mas grandes, no ordenables, pero cero coordinacion necesaria.
7. Disenar una cola de tareas (tipo Celery o SQS)
Por que se pregunta: Prueba tu comprension del procesamiento asincrono, fundamental para cualquier sistema a gran escala. Amazon pregunta variantes de esto regularmente.
Conceptos clave: Entrega al-menos-una-vez, timeout de visibilidad, colas de mensajes fallidos (dead letter queues), colas prioritarias, escalado de workers, desafios del procesamiento exactamente-una-vez.
Pista de enfoque: Componentes principales: los productores envian tareas a una cola, los consumidores las extraen y procesan. Usa un timeout de visibilidad — si un worker no confirma dentro de N segundos, la tarea vuelve a estar disponible. Anade una cola de mensajes fallidos para tareas que fallan repetidamente. La discusion interesante es sobre garantias de orden: FIFO estricto es costoso a escala, asi que la mayoria de sistemas ofrecen orden de mejor esfuerzo. Nombra ese trade-off.
8. Disenar un rate limiter API para un servicio cloud
Por que se pregunta: Extiende el limitador basico a un contexto SaaS multi-tenant. Ahora gestionas diferentes niveles, cuotas y la logica de negocio alrededor del throttling diferenciado para clientes de pago.
Conceptos clave: Limites por nivel, conteo distribuido, gestion de cuotas, degradacion elegante (respuestas 429 con headers Retry-After), analytics para seguimiento de uso.
Pista de enfoque: Superpone los limites: globales, por tenant, por endpoint. Almacena contadores en Redis, indexados por ID de tenant + endpoint + ventana temporal. Usa contadores de ventana deslizante para un comportamiento mas suave que ventanas fijas. La decision critica de negocio: que pasa cuando un cliente premium alcanza su limite? Encolar las peticiones brevemente en vez de rechazar en seco? Ese es el tipo de pensamiento orientado a producto que los entrevistadores valoran.
9. Disenar un CDN (red de distribucion de contenido)
Por que se pregunta: Los CDN son infraestructura invisible que los candidatos usan frecuentemente sin entender. Esta pregunta prueba si comprendes la distribucion geografica, las jerarquias de cache y la invalidacion de cache.
Conceptos clave: Servidores edge, origin pull vs push, jerarquias de cache (edge, regional, origin shield), TTL e invalidacion de cache, enrutamiento basado en DNS, hashing consistente para nodos de cache.
Pista de enfoque: Empieza por el camino de lectura: la peticion del usuario llega al DNS, se enruta al servidor edge mas cercano. Un cache hit retorna inmediatamente; un cache miss tira del origen (posiblemente a traves de un nivel regional para reducir la carga en el origen). Discute estrategias de invalidacion — TTL es simple pero puede servir contenido obsoleto, las APIs de purga son precisas pero complejas. El punto avanzado: como manejas los cache stampedes cuando un objeto popular expira simultaneamente en todos los edges?
10. Disenar un crawler web (basico)
Por que se pregunta: El crawling es un problema clasico de sistemas distribuidos. Requiere coordinacion, cortesia (no bombardear sitios), deduplicacion y manejar el desorden del web real.
Conceptos clave: Estrategia de crawling BFS vs DFS, frontera de URLs, politicas de cortesia (robots.txt, rate limiting por dominio), deduplicacion de URLs (filtros de Bloom), coordinacion distribuida de tareas.
Pista de enfoque: La frontera de URLs es la estructura de datos central — una cola prioritaria de URLs a visitar con restricciones de cortesia por dominio. Los workers extraen URLs, obtienen paginas, extraen enlaces y empujan nuevas URLs. Usa filtros de Bloom para deduplicacion (ya hemos visto esta URL?). Discute como escalar: particiona la frontera por dominio para que cada worker maneje un subconjunto. La sutileza es manejar las trampas — paginacion infinita, URLs dinamicas, trampas para crawlers.
Intermedio (Preguntas 11-20)
Estas preguntas aparecen en entrevistas para ingenieros senior. Involucran multiples subsistemas interactuando, requisitos de tiempo real o desafios complejos de consistencia. Necesitas demostrar pensamiento de trade-offs, no solo ensamblaje de componentes.
11. Disenar un sistema de mensajeria (tipo WhatsApp o Slack)
Por que se pregunta: La mensajeria en tiempo real combina conexiones persistentes, ordenamiento de mensajes, garantias de entrega y deteccion de presencia. Meta y Amazon la preguntan frecuentemente.
Conceptos clave: WebSockets para conexiones persistentes, ordenamiento de mensajes (numeros de secuencia por conversacion), confirmaciones de lectura, servicio de presencia (basado en heartbeats), almacenamiento de mensajes (escritura intensiva, ordenado por tiempo), fan-out de chat grupal.
Pista de enfoque: Cada usuario mantiene una conexion WebSocket hacia un servidor de chat. Un gestor de conexiones rastrea que servidor aloja a cada usuario. Para mensajes 1:1, enruta directamente via el mapa de conexiones. Para chat grupal, distribuye a todos los servidores de los miembros. Almacena mensajes en una base optimizada para series temporales (Cassandra funciona bien). La parte dificil: que pasa cuando un usuario esta desconectado? Encola mensajes y entrega al reconectar. Discute las implicaciones del cifrado de extremo a extremo si te lo preguntan.
12. Disenar un feed de noticias (tipo Facebook o Twitter)
Por que se pregunta: El problema del fan-out es central en redes sociales. Esta pregunta prueba tu capacidad para razonar sobre trade-offs push vs pull a escala masiva.
Conceptos clave: Fan-out-on-write vs fan-out-on-read, problema de las celebridades (usuarios con millones de seguidores), cache de timeline, algoritmos de ranking, consistencia eventual.
Pista de enfoque: Enfoque hibrido: fan-out-on-write para usuarios normales (precalcular y empujar a los timelines de seguidores), fan-out-on-read para celebridades (obtener y fusionar en tiempo de lectura). Almacena timelines en listas Redis, limitadas a unos pocos cientos de entradas. La capa de ranking se situa entre el timeline crudo y el usuario — reordena, deduplica e inserta anuncios. Discute que significa “consistencia eventual” aqui: la publicacion de tu amigo podria tardar unos segundos en aparecer, y eso es aceptable.
13. Disenar Instagram
Por que se pregunta: Es una plataforma social con mucho contenido multimedia que combina almacenamiento de contenido, generacion de feed e interacciones en tiempo real. Prueba tu capacidad para manejar objetos binarios grandes junto con datos estructurados.
Conceptos clave: Almacenamiento de imagenes/video y entrega por CDN, generacion de feed (similar al feed de noticias), servicios de likes/comentarios, algoritmos de exploracion/descubrimiento, pipeline de procesamiento de imagenes (redimensionado, filtro, miniatura).
Pista de enfoque: Separa el camino de subida del camino de lectura. Las subidas van al almacenamiento de objetos (S3), disparan un pipeline de procesamiento asincrono (redimensionado a multiples formatos, generacion de miniaturas), luego actualizan metadatos en la base. Las lecturas se sirven desde CDN. El feed es una variante del problema de feed de noticias — fan-out-on-write para la mayoria de usuarios. La funcionalidad Explorar anade una capa de recomendacion basada en senales de engagement. Discute como manejarias un usuario subiendo una imagen de 50 MB en una conexion movil inestable (subidas por trozos, reanudabilidad).
14. Disenar un sistema de autocompletado de busqueda
Por que se pregunta: Es critico en latencia (los resultados deben aparecer mientras escribes) e intensivo en datos (miles de millones de consultas). Google la pregunta por razones obvias.
Conceptos clave: Estructura de datos trie, top-K de consultas frecuentes, precalculo vs ranking en tiempo real, pipeline de recopilacion de datos, capa de personalizacion, servicio desde memoria.
Pista de enfoque: Precalcula las completaciones mas populares usando un trie donde cada nodo almacena las N sugerencias mas frecuentes. Sirve desde memoria para latencia sub-10ms. Un pipeline offline separado procesa logs de busqueda, agrega frecuencias y reconstruye el trie periodicamente. La sutileza: como manejas consultas trending que explotan de repente? Una capa en tiempo real que detecta anomalias de frecuencia e inyecta tendencias en el conjunto precalculado.
15. Disenar un crawler web a gran escala (escala Google)
Por que se pregunta: Extiende el crawler basico a miles de millones de paginas. Ahora gestionas priorizacion, frescura, deteccion de contenido duplicado y coordinacion distribuida masiva.
Conceptos clave: Priorizacion de URLs (informada por PageRank), fingerprinting de contenido (simhash para deteccion de casi-duplicados), planificacion de re-crawl basada en frecuencia de cambio, frontera de crawl distribuida, cache DNS, cortesia a gran escala.
Pista de enfoque: Particiona el espacio de URLs entre nodos crawlers por dominio. Cada nodo mantiene una cola prioritaria local. Un scheduler central asigna dominios y gestiona prioridades globales. Usa simhash para detectar contenido casi identico (URLs diferentes, mismo articulo). La frecuencia de re-crawl debe ser adaptativa — paginas que cambian cada hora se rastrean cada hora; paginas estaticas se rastrean mensualmente. La discusion avanzada: como respetas la restriccion de cortesia sin infrautilizar tu flota de crawlers?
16. Disenar un sistema de almacenamiento de archivos (tipo Google Drive o Dropbox)
Por que se pregunta: Prueba sincronizacion en tiempo real, resolucion de conflictos, fragmentacion de archivos grandes y soporte offline. Es una pregunta favorita en Google y Meta.
Conceptos clave: Fragmentacion de archivos y deduplicacion, protocolos de sincronizacion (transformacion operacional o CRDT para conflictos), servicio de metadatos, almacenamiento por bloques, versionado, deteccion de cambios del lado del cliente (watchers del sistema de archivos).
Pista de enfoque: Divide archivos en fragmentos de tamano fijo y almacenalos por hash de contenido (permite deduplicacion entre usuarios). Un servicio de metadatos rastrea la estructura de archivos, permisos y mapeos de fragmentos. La sincronizacion usa un canal de notificaciones — cuando un archivo cambia, el servidor notifica a los clientes conectados para que descarguen los fragmentos actualizados. Resolucion de conflictos: para ediciones simultaneas, guarda ambas versiones y deja que el usuario resuelva. El insight de rendimiento: solo sincroniza los fragmentos modificados, no archivos enteros. Un archivo de 1 GB con un cambio de un byte deberia transferir un solo fragmento, no 1 GB.
17. Disenar una plataforma de streaming de video (tipo YouTube o Netflix)
Por que se pregunta: El video implica almacenamiento masivo, pipelines de transcodificacion, streaming de bitrate adaptativo y entrega global. Prueba tu pensamiento de sistema de extremo a extremo.
Conceptos clave: Pipeline de transcodificacion de video (multiples resoluciones/codecs), streaming de bitrate adaptativo (HLS/DASH), CDN para entrega, URLs prefirmadas para control de acceso, motor de recomendacion, conteo de vistas a gran escala.
Pista de enfoque: Camino de subida: el cliente envia el video en crudo al almacenamiento de objetos, lo que dispara un pipeline de transcodificacion produciendo multiples variantes de resolucion/bitrate. Los metadatos (titulo, miniaturas, formatos) se almacenan en base de datos. Reproduccion: el cliente solicita un archivo manifest listando las calidades disponibles, luego selecciona adaptativamente segmentos segun el ancho de banda. Los segmentos de video se sirven desde CDN. La decision de diseno interesante: como cuentas vistas de forma fiable a escala de YouTube? Procesamiento por lotes con deduplicacion, no contadores en tiempo real.
18. Disenar un servicio de transporte compartido (tipo Uber o Lyft)
Por que se pregunta: El matching de ubicacion en tiempo real, consultas geoespaciales y precios dinamicos crean un problema de diseno rico. Comun en Amazon y Google.
Conceptos clave: Indexacion geoespacial (geohash, celdas S2), seguimiento de ubicacion en tiempo real, algoritmo de matching, estimacion de ETA, surge pricing, maquina de estados del viaje, comunicacion conductor/pasajero.
Pista de enfoque: Los conductores reportan continuamente su ubicacion; almacena posiciones en un indice geoespacial (cuadricula geohash). Cuando un pasajero hace una solicitud, consulta conductores cercanos via geohash, clasifica por distancia y ETA, y despacha. Un servicio de viaje gestiona la maquina de estados (solicitado, emparejado, en camino, en curso, completado). El tema avanzado: el surge pricing requiere un ratio oferta/demanda en tiempo real por zona geografica. Discute como evitarias la oscilacion (los precios suben, los conductores llegan, los precios bajan, los conductores se van).
19. Disenar un sistema de monitoreo de metricas (tipo Datadog o Prometheus)
Por que se pregunta: Prueba tu comprension de datos de series temporales, alto rendimiento de escritura, agregacion, alertas y eficiencia de almacenamiento.
Conceptos clave: Bases de datos de series temporales, write-ahead logs, downsampling para datos antiguos, modelos de recoleccion push vs pull, pipelines de agregacion, motor de reglas de alertas, optimizacion de consultas de dashboard.
Pista de enfoque: Agentes en cada host envian metricas a un servicio de recoleccion, que escribe en una base de series temporales (particionamiento por nombre de metrica + rango temporal). Datos recientes en resolucion completa; datos mas antiguos submuestreados (promedios por minuto se convierten en promedios por hora). Las alertas evaluan reglas contra datos recientes y disparan notificaciones. El insight de almacenamiento: los datos de series temporales se comprimen extremadamente bien porque valores consecutivos suelen ser similares — usa codificacion delta o compresion gorilla.
20. Disenar un editor de documentos colaborativo (tipo Google Docs)
Por que se pregunta: La colaboracion en tiempo real es uno de los problemas distribuidos mas dificiles en tecnologia de consumo. Prueba resolucion de conflictos, transformaciones operacionales y sincronizacion en tiempo real.
Conceptos clave: Transformacion Operacional (OT) o CRDTs, conciencia de cursores y presencia, conexiones WebSocket, versionado de documentos, undo/redo en contexto colaborativo, control de acceso.
Pista de enfoque: Cada cliente mantiene una copia local y envia operaciones (insercion, eliminacion) al servidor. El servidor usa OT para transformar operaciones concurrentes de modo que converjan al mismo estado. Las operaciones transformadas se difunden a todos los clientes conectados. Almacena el registro de operaciones para undo/redo e historial de versiones. El trade-off clave: OT esta probado pero es complejo; los CRDTs son mas simples de razonar pero pueden tener mayor overhead de estado. Elige uno y justifica.
Avanzado (Preguntas 21-30)
Este es territorio de staff/senior-staff. Estas preguntas involucran orquestacion entre sistemas, requisitos de consistencia complejos, distribucion a escala global o profundidad especifica del dominio. Se espera credito parcial — el objetivo es ver hasta donde llega tu razonamiento.
21. Disenar una cola de mensajes distribuida (tipo Kafka)
Por que se pregunta: Prueba una comprension profunda de los fundamentos de sistemas distribuidos: replicacion, ordenamiento, particionamiento, grupos de consumidores y semantica exactamente-una-vez.
Conceptos clave: Particionamiento por topic, grupos de consumidores, gestion de offsets, replicacion (ISR — in-sync replicas), compactacion de logs, entrega exactamente-una-vez (productores idempotentes + escrituras transaccionales), transferencia zero-copy.
Pista de enfoque: Los topics se dividen en particiones, cada una un log append-only almacenado en un broker. Los productores escriben a los lideres de particion; las replicas en el conjunto ISR replican sincronamente. Los consumidores de un grupo poseen cada uno un subconjunto de particiones (rebalanceado al unirse/salir). Los offsets rastrean el progreso de consumo. La discusion avanzada: como logras exactamente-una-vez? Productores idempotentes (numeros de secuencia por particion) mas escrituras transaccionales que hacen commit atomicamente de offsets y registros de salida.
22. Disenar un cache distribuido (tipo cluster Memcached/Redis)
Por que se pregunta: El cache parece simple hasta que lo distribuyes. Prueba hashing consistente, estrategias de invalidacion de cache, proteccion contra thundering herds y manejo de claves calientes.
Conceptos clave: Hashing consistente con nodos virtuales, patrones cache-aside vs read-through vs write-through, thundering herd (basado en locks vs expiracion anticipada probabilistica), replicacion de claves calientes, precalentamiento de cache, politicas de desalojo.
Pista de enfoque: Usa hashing consistente para distribuir claves entre nodos de cache con nodos virtuales para balance. Para lecturas: patron cache-aside (la app verifica cache, recurre a la base, puebla el cache). Proteccion contra thundering herd: cuando una clave popular expira, usa un lock distribuido para que solo una peticion la reconstruya mientras las demas esperan. Claves calientes: replica en multiples nodos y balancea la carga de lecturas entre ellos. Discute la pesadilla de la invalidacion: que estrategia asegura consistencia del cache con la base de datos?
23. Disenar un sistema de pagos (tipo Stripe)
Por que se pregunta: Los sistemas financieros exigen correccion extrema. Prueba idempotencia, procesamiento exactamente-una-vez, transacciones distribuidas y auditabilidad. Comun en Amazon y en roles adyacentes a fintech.
Conceptos clave: Claves de idempotencia, transacciones distribuidas (patron saga), contabilidad de partida doble, cumplimiento PCI, maquina de estados del pago, entrega de webhooks, reconciliacion, seguridad de reintentos.
Pista de enfoque: Cada peticion de pago lleva una clave de idempotencia para prevenir dobles cobros. Usa una maquina de estados: creado, procesando, exitoso, fallido. El servicio de pagos coordina entre verificacion del comerciante, deteccion de fraude e integracion con el procesador de pagos via el patron saga (cada paso tiene una accion compensatoria para rollback). La contabilidad de partida doble asegura que cada debito tiene un credito correspondiente. El tema avanzado: reconciliacion — como detectas y resuelves discrepancias entre tus registros y los del procesador de pagos al final del dia?
24. Disenar un motor de busqueda (tipo Google Search)
Por que se pregunta: Es el problema definitivo de system design full-stack. Crawling, indexacion, ranking, servicio — cada uno es un sistema en si mismo. Generalmente preguntado en Google y a veces en Amazon.
Conceptos clave: Indice invertido, ranking TF-IDF y BM25, PageRank, particionamiento de indice (por documento vs por termino), analisis de consultas, correccion ortografica, generacion de fragmentos, servicio por niveles.
Pista de enfoque: Tres subsistemas principales: crawl (recopilar paginas), index (construir un indice invertido mapeando terminos a documentos con posiciones y frecuencias), servicio (analizar consulta, consultar indice, rankear resultados). Particiona el indice por rangos de documentos entre servidores; scatter-gather en tiempo de consulta. El ranking combina relevancia textual (BM25) con analisis de enlaces (PageRank) y senales de frescura. La profundidad interesante: indexacion por niveles — sirve resultados desde un indice “caliente” pequeno primero (paginas populares), solo consulta el indice completo si es necesario. Esto reduce drasticamente el coste de servicio.
25. Disenar un sistema de reservas de hotel/vuelo (tipo Booking.com)
Por que se pregunta: Los sistemas de inventario enfrentan el problema de la doble reserva, que es un desafio de consistencia distribuida. Tambien involucra busqueda a traves de espacios de atributos complejos.
Conceptos clave: Bloqueo de inventario (pesimista vs optimista), consistencia eventual para busqueda vs consistencia fuerte para reserva, indexacion de busqueda con filtros, motor de precios, estrategias de overbooking, integracion de pagos.
Pista de enfoque: Separa el camino de busqueda (lectura intensiva, eventualmente consistente, servido desde Elasticsearch con datos desnormalizados) del camino de reserva (consistencia fuerte, serializado a traves de la base de datos). Para reservas: bloqueo optimista con verificaciones de version — lee la version actual de la habitacion, intenta la escritura, reintenta si alguien mas reservo primero. La sutileza de negocio: los hoteles sobrevendan intencionalmente un pequeno porcentaje, asi que tu sistema debe soportar umbrales de overbooking configurables. Discute como los resultados de busqueda muestran “3 habitaciones disponibles” sin ser una garantia de inventario en tiempo real.
26. Disenar un servicio de proximidad (tipo Yelp o Google Maps nearby)
Por que se pregunta: La busqueda geoespacial a gran escala no es trivial. Prueba tu conocimiento de indexacion espacial, ranking por distancia mas relevancia y manejo de radios de consulta variables.
Conceptos clave: Indexacion geoespacial (geohash, quadtree, geometria S2), consultas por radio, ranking (distancia, calificacion, relevancia), cache por region, expansion dinamica de radio, pipeline de ingesta de datos de negocios.
Pista de enfoque: Indexa negocios usando geohash — cada negocio obtiene un prefijo geohash basado en su ubicacion. Para una consulta “restaurantes cerca de mi”, calcula el geohash del usuario y consulta las celdas circundantes. Usa un quadtree para areas de densidad variable (mas granularidad en Manhattan, menos en zonas rurales). Rankea resultados por una puntuacion ponderada de distancia, calificacion y relevancia. El insight avanzado: geohash tiene casos limite en las fronteras de celdas — un restaurante a 50 metros podria estar en una celda diferente. Consulta celdas vecinas para manejar esto.
27. Disenar una base de datos distribuida a escala global (tipo Spanner)
Por que se pregunta: Es la pregunta de sistemas mas profunda que puedes recibir. Prueba comprension de protocolos de consenso, sincronizacion de reloj y los limites fundamentales de la computacion distribuida.
Conceptos clave: Consenso Paxos/Raft, TrueTime (GPS + relojes atomicos para incertidumbre de reloj acotada), transacciones externamente consistentes, gestion de shards, commit en dos fases entre shards, transacciones de solo lectura a un timestamp.
Pista de enfoque: Los datos se fragmentan entre regiones, cada shard replicado via Paxos para tolerancia a fallos. Dentro de un shard, un lider maneja lecturas y escrituras. Las transacciones entre shards usan commit en dos fases coordinado por un gestor de transacciones. El insight revolucionario de Spanner: TrueTime proporciona incertidumbre de reloj acotada, permitiendo lecturas externamente consistentes sin coordinacion entre regiones esperando que termine la ventana de incertidumbre. Discute por que esto importa — permite lecturas globalmente consistentes en cualquier replica.
28. Disenar un ranking en tiempo real para un juego
Por que se pregunta: Parece simple pero involucra rankear millones de jugadores con actualizaciones en tiempo real. Prueba tu comprension de estructuras de datos ordenadas a gran escala y patrones de consulta.
Conceptos clave: Sorted sets de Redis, estrategias de particionamiento para rankings globales, rankings aproximados vs exactos, rendimiento de actualizacion de puntajes, rankings regionales vs globales, rankings con ventana temporal.
Pista de enfoque: Los sorted sets de Redis ofrecen actualizaciones en O(log N) y consultas de rango en O(log N) — perfecto para rankings de hasta decenas de millones de entradas en un solo nodo. Para mayor escala, particiona por rangos de puntaje y mantiene un conteo por particion para calcular el rango global. Los rankings con ventana temporal (diarios, semanales) necesitan sorted sets separados con limpieza basada en TTL. El trade-off interesante: el ranking global exacto con mas de 100M jugadores es costoso — seria aceptable un rango aproximado (“top 1%”) para contextos no competitivos?
29. Disenar un planificador de tareas distribuido (tipo Airflow a gran escala)
Por que se pregunta: La orquestacion de workflows involucra ejecucion de DAGs, gestion de dependencias, recuperacion ante fallos y asignacion de recursos. Comun en Google y Amazon donde los pipelines de datos son infraestructura critica.
Conceptos clave: Representacion de DAG, ordenamiento topologico para orden de ejecucion, maquina de estados de tareas, bloqueo distribuido para asignacion de tareas, deteccion de fallos por heartbeat, politicas de reintento, soporte de backfill, gestion de pools de recursos.
Pista de enfoque: Almacena los DAGs de workflow en una base de datos. Un servicio scheduler evalua los DAGs periodicamente: para cada uno, verifica si las dependencias se cumplen y encola las tareas listas en una cola de tareas distribuida. Los workers extraen tareas, las ejecutan y reportan estado. Usa heartbeats para detectar workers atascados y reasignar sus tareas. La complejidad: que pasa cuando una tarea en medio de un DAG falla? Soporta politicas configurables — reintentar N veces, saltar y continuar aguas abajo, o fallar el DAG entero. Discute como manejarias backfills (reejecucion de ejecuciones historicas del DAG).
30. Disenar un motor de emparejamiento de bolsa de valores
Por que se pregunta: Es posiblemente la pregunta de system design mas dificil. Exige latencia extremadamente baja, ordenamiento deterministico y correccion bajo alto rendimiento. Preguntada en entrevistas fintech de alto nivel.
Conceptos clave: Libro de ordenes (prioridad precio-tiempo), algoritmos de emparejamiento (precio-tiempo, pro-rata), secuenciador para ordenamiento deterministico, event sourcing, co-ubicacion para latencia, difusion de datos de mercado, circuit breakers.
Pista de enfoque: El nucleo es un motor de emparejamiento de un solo hilo procesando ordenes secuencialmente desde un secuenciador (el ordenamiento deterministico no es negociable). El libro de ordenes mantiene los lados de compra y venta ordenados por precio, luego por tiempo. Cuando una orden entrante coincide (precio de compra >= precio de venta), ejecuta la operacion y emite eventos. El event sourcing significa que el registro de ordenes ES la fuente de verdad; el estado puede reconstruirse reejecutandolo. El desafio de escalado: no puedes escalar horizontalmente el motor de emparejamiento para un solo instrumento porque el ordenamiento debe ser deterministico. Escala fragmentando por instrumento. Discute como los datos de mercado (actualizaciones de precios) se difunden a millones de suscriptores con latencia minima.
Como Practicar Estas Preguntas de Manera Efectiva
Recopilar preguntas es la parte facil. Lo que separa a quienes consiguen ofertas de quienes coleccionan emails de rechazo es como practican.
Usa un framework, no un lienzo en blanco. Si te sientas frente a “Disena YouTube” y simplemente empiezas a dibujar, pasaras diez minutos mirando la pizarra. Usa un enfoque estructurado — delimita el problema, estima la escala, define las APIs, luego arquitectura. Si aun no tienes un framework, el metodo URDGE es un buen punto de partida.
Cronometrate. Las entrevistas reales duran 35-45 minutos. Practica bajo la misma restriccion. Una solucion elegante que toma noventa minutos no vale nada en contexto de entrevista.
Habla en voz alta. El system design es un ejercicio verbal. No estas escribiendo codigo; estas narrando tu pensamiento. Practica discutir trade-offs, aunque se sienta raro estando solo. Grabate si puedes soportar escucharte despues.
Profundiza tres niveles en los temas clave. No te conformes con saber que Redis existe. Sabe cuando elegirias Redis sobre Memcached, que politicas de desalojo soporta y que pasa con tu cache durante un failover. Tres niveles de “por que” sobre cualquier tecnologia cubriran la mayoria de preguntas de seguimiento de los entrevistadores.
Practica en parejas. Busca un amigo que tambien se este preparando y turnense entrevistandose mutuamente. El rol de entrevistador te ensena tanto como el de candidato — empiezas a notar que hace que una respuesta sea convincente versus vaga.
Y lleva un registro de tus respuestas. Para una estructura rellenable que puedas reutilizar en las treinta preguntas, consulta nuestro template de respuesta de system design.
FAQ
P: Las FAANG realmente hacen estas preguntas exactas?
La mayoria, si — o variantes cercanas. “Disena un sistema de chat” podria convertirse en “Disena Facebook Messenger” o “Disena Slack”, pero el problema subyacente es identico. Las empresas rotan sus bancos de preguntas, pero los patrones subyacentes han sido estables durante anos. Prepararte para el patron te da mas cobertura que memorizar preguntas especificas de una empresa.
P: Cuantas de estas deberia practicar antes de la entrevista?
Ocho a diez, distribuidas en los tres niveles de dificultad. El objetivo no es tener una respuesta preparada para cada pregunta — es desarrollar fluidez con los bloques fundamentales (cache, colas, particionamiento, replicacion) para poder ensamblarlos sobre la marcha. Despues de ocho problemas bien practicados, reconoceras los patrones en cualquier pregunta nueva.
P: Debo memorizar arquitecturas o entender los bloques fundamentales?
Los bloques fundamentales, sin duda. Las arquitecturas memorizadas se desmoronan bajo las preguntas de seguimiento. Si realmente entiendes el hashing consistente, puedes aplicarlo a un cache distribuido, un CDN o una estrategia de particionamiento — incluso si nunca has visto la pregunta especifica. Los bloques fundamentales son la habilidad transferible; las arquitecturas son solo ensamblajes.
P: Cual es el error mas grande que cometen los candidatos en entrevistas de system design?
Lanzarse a la solucion. Escuchan “Disena Uber” e inmediatamente empiezan a dibujar microservicios. Los mejores candidatos pasan los primeros cinco a diez minutos haciendo preguntas, definiendo alcance y estimando escala. Para cuando toman el marcador, saben exactamente que estan construyendo y por que. Esa inversion inicial ahorra tiempo y produce un diseno enfocado y coherente en lugar de un desorden tentacular.
El system design es solo una pieza del rompecabezas. Para un plan de preparacion completo que cubra rondas de codigo, entrevistas de comportamiento y logistica, lee como preparar una entrevista tecnica. Y cuando estes listo para estructurar tus respuestas de practica, consulta el template de respuesta de system design.
Terminaste de leer? Unete al acceso anticipado —>