Consigna y contexto aplicable
Diseña el servicio de backend que devuelve las 10 mejores sugerencias de consultas para un prefijo escrito. Asume 50 millones de usuarios activos diarios, 10 búsquedas por usuario al día, cinco solicitudes de sugerencia por búsqueda, un pico de 150 000 solicitudes por segundo, un objetivo de latencia p99 de 50 ms, un objetivo de actualización de popularidad de 15 minutos y un objetivo de eliminación por políticas de un minuto.
Estas son suposiciones de entrevista, no datos medidos de producción. El diseño base sirve sugerencias de popularidad anónimas y específicas por configuración regional (locale). El componente del navegador, la corrección ortográfica, la compleción semántica y la personalización por usuario quedan fuera del alcance inicial. El servicio no debe exponer consultas raras o no permitidas simplemente porque aparecen en los registros.
Este es un problema de diseño de sistemas porque el trabajo central abarca la ingesta de eventos, el ranking, la construcción de índices inmutables, el servicio online, el comportamiento de caché y shards, y la publicación segura. Un componente de autocompletado frontend puede consumir esta API, mientras que un Trie es solo una posible representación de índice local.
Qué evalúa el entrevistador
Una respuesta sólida primero separa la ruta de aprendizaje de escritura intensiva de la ruta de servicio de lectura intensiva. Escanear registros sin procesar o clasificar candidatos en cada pulsación de tecla no puede cumplir con un objetivo estricto de latencia de cola. La agregación, las comprobaciones de elegibilidad, la moderación y la mayor parte del ranking deben ocurrir antes de que lleguen las solicitudes; la ruta online realiza una búsqueda de prefijo acotada y devuelve una lista pequeña.
La segunda señal es el razonamiento cuantitativo. Las suposiciones diarias implican 2500 millones de solicitudes: 50 millones por 10 por cinco. Eso es aproximadamente 28 900 solicitudes por segundo en promedio, por lo que el pico establecido de 150 000 es aproximadamente un factor de pico de cinco veces. Con una respuesta estimada de 1 KB, la carga útil de respuesta máxima es de aproximadamente 150 MB/s antes de la sobrecarga de protocolo y la replicación. Estos cálculos guían los objetivos de replicación, caché y pruebas de carga; no pretenden dimensionar la memoria sin medir el índice codificado.
La tercera señal es la corrección en la publicación. Un índice parcialmente construido o enrutado de forma inconsistente puede devolver resultados faltantes o con un ranking diferente. Los candidatos sólidos construyen un artefacto inmutable versionado, lo validan, lo cargan junto a la versión anterior, activan atómicamente el enrutamiento y conservan la versión buena anterior para rollback.
Por último, la popularidad no es lo mismo que la elegibilidad. Los registros de búsqueda pueden contener datos personales, manipulación y texto dañino. Los umbrales de frecuencia mínima, los controles de retención, las señales contra el abuso, la moderación antes de la publicación y una ruta de denegación de emergencia más rápida forman parte de la corrección.
Preguntas para clarificar antes de responder
- ¿Qué representa una sugerencia? Las compleciones de consultas, las entidades de productos y los destinos de navegación necesitan diferentes fuentes de candidatos y características de ranking. El diseño base devuelve cadenas de consulta completas.
- ¿Qué coincidencias se requieren? La búsqueda solo por prefijo permite un índice de prefijos ordenado y compacto. Las coincidencias infijas, difusas (fuzzy) o semánticas agregan generadores de candidatos y hacen que el presupuesto online sea más difícil de acotar.
- ¿Qué tan reciente debe ser cada cambio? La popularidad puede tolerar los 15 minutos asumidos; las eliminaciones por políticas necesitan un minuto. Esto conduce a un índice base versionado más una capa de denegación actualizada independientemente.
- ¿Los resultados son globales o personalizados? Los resultados globales se pueden almacenar intensamente en caché. La personalización reduce el uso compartido de la caché y agrega latencia de consentimiento, eliminación y obtención de características. Se excluye inicialmente.
- ¿Cómo se definen la configuración regional y la normalización? La conversión a minúsculas, la escritura, los acentos y los límites de palabras difieren según la configuración regional. El índice y la consulta deben usar la misma política de normalización versionada.
- ¿Qué sucede con los prefijos vacíos y de un solo carácter? Son extremadamente calientes y pueden revelar tendencias amplias. El sistema base devuelve una lista curada por configuración regional para entradas vacías y una lista precomputada para un solo carácter.
- ¿Cuáles son los requisitos de seguridad y privacidad? Determinan la retención de registros, los umbrales de agregación, el flujo de trabajo de los revisores, el almacenamiento regional y si un candidato puede ingresar alguna vez al índice.
Estructura de respuesta en 30 segundos
“Dividiría el sistema en una ruta de construcción offline y una ruta de búsqueda online acotada. Los eventos de búsqueda ingresan a un flujo, se normalizan y agregan por configuración regional y ventana de tiempo, y luego pasan por filtros de frecuencia, abuso, privacidad y moderación. Un trabajo de ranking escribe los mejores candidatos en un índice de prefijos versionado. Tras la validación, las réplicas de servicio cargan la versión inmutable y el enrutamiento cambia de forma atómica. Las solicitudes online normalizan el prefijo, consultan una caché de prefijos calientes, se enrutan al shard de configuración regional y prefijo, aplican la capa de denegación rápida y devuelven diez resultados. Dimensionaría a partir del pico de 150 000, dividiría los prefijos calientes cuando sea necesario, mantendría el índice anterior para rollback y mediría la latencia p99, la cobertura, el recall de seguridad, la tasa de versiones obsoletas y la calidad del ranking.”
Análisis detallado paso a paso
Paso 1: Deducir el presupuesto y el contrato
Usa una API de lectura idempotente pequeña:
GET /v1/suggestions?prefix=iph&locale=en-US&limit=10
200 {
"suggestions": [
{ "text": "iphone charger", "id": "q_7f2" }
],
"indexVersion": "2026-07-19T17:30Z"
}Acota limit, limita la longitud del prefijo normalizado, rechaza configuraciones regionales no admitidas y nunca aceptes pesos de ranking del cliente. El ID opaco estable admite análisis sin tratar el texto para mostrar como un identificador. indexVersion hace observables las respuestas obsoletas o de versiones mixtas.
El cálculo diario de 2500 millones da aproximadamente 28 900 QPS promedio. El pico provisto de 150 000 es el objetivo de capacidad. Si una respuesta es de aproximadamente 1 KB, servir 150 MB/s requiere réplicas regionales y transporte comprimido. La capacidad de caché y la RAM de índice aún requieren muestras de producción: serializar artefactos representativos, medir bytes por prefijo y entrada top-K, y luego agregar replicación y margen de seguridad. Multiplicar un tamaño supuesto de nodo de Trie por el recuento de candidatos produciría una falsa precisión.
Paso 2: Construir candidatos sin publicar registros sin procesar
Los clientes emiten un evento de búsqueda completada con ID de consulta, configuración regional normalizada, contexto aproximado, marca de tiempo, señales de resultados y una clave de actor efímera que preserva la privacidad utilizada únicamente para la agregación acotada. El servicio de ingesta valida el esquema y descarta bots evidentes antes de enviarlo a un flujo de solo anexado. La agregación en ventanas computa recuentos de actores distintos y señales de calidad; los identificadores de usuario sin procesar nunca se convierten en parte de una clave de sugerencia.
La canalización de candidatos aplica un umbral mínimo de usuarios distintos, controles de tasa y abuso, reglas de privacidad y retención, y clasificación de políticas. Luego clasifica a los candidatos elegibles utilizando una combinación documentada de popularidad, decaimiento por recencia, calidad del resultado y reglas editoriales. Los pesos exactos se aprenden y prueban; no son constantes universales. Mantén los candidatos rechazados y los motivos en un almacén de auditoría restringido, no en el índice de servicio.
El ranking a partir de clics observados puede reforzar lo que ya se mostraba. Usa juicios de relevancia offline y experimentos controlados junto con el engagement, y monitorea la cobertura de sugerencias, la tasa de búsquedas sin resultados, las quejas y la concentración de exposición. La moderación debe realizarse antes de la construcción del índice porque las sugerencias automáticas derivadas de registros pueden reproducir texto dañino o sesgado.
Paso 3: Materializar un índice de prefijos acotado
Para cada sugerencia elegible, genera prefijos bajo la misma normalización consciente de la configuración regional utilizada online. Almacena solo una lista superior acotada por prefijo (por ejemplo, los mejores 20 candidatos cuando la API devuelve 10), de modo que la búsqueda y el filtrado permanezcan acotados. Los candidatos adicionales permiten la deduplicación y las eliminaciones de emergencia sin recorrer un subárbol.
Un Trie o un transductor de estados finitos puede representar prefijos compartidos; una tabla clave-valor ordenada con clave de configuración regional más prefijo es operativamente más simple y puede comprimirse bien. Elige después de evaluar comparativamente el tamaño del artefacto, el tiempo de construcción, el p99 de búsqueda y el flujo de trabajo de actualización. El sugeridor de compleción de Elasticsearch ilustra el mismo balance: la búsqueda rápida de prefijos utiliza una estructura en memoria que es costosa de construir, y los pesos y contextos influyen en el ranking y el filtrado.
El alcance base es la compleción exacta de prefijos. La compleción difusa es un generador separado porque la expansión por distancia de edición cambia el recall, el costo de CPU y el análisis de seguridad. No debería compartir silenciosamente la misma promesa de latencia.
Paso 4: Publicar versiones inmutables de forma segura
Cada compilación tiene una marca de agua de entrada, versión de normalización, versión del ranker, versión de política, suma de comprobación y hora de creación. La validación comprueba el esquema, el recuento de candidatos, frases de prueba prohibidas, aislamiento de configuración regional, resolución determinista de empates, muestras de búsqueda, tamaño del artefacto y latencia en una réplica cargada.
Las réplicas cargan el nuevo índice inmutable junto al activo. Un informe de estado confirma su suma de comprobación y consultas representativas. Luego, el plano de control cambia atómicamente la versión activa para un grupo de shards. Durante el despliegue, las solicitudes permanecen ancladas a una sola versión; se miden los resultados mixtos. Conserva la versión buena anterior hasta que la nueva versión supere una ventana canary, luego revierte el enrutamiento si la latencia, la seguridad o la cobertura empeoran.
Una compilación fallida o tardía no reemplaza a un índice en buen estado. La frescura es un SLO, no un permiso para publicar un artefacto inválido.
Paso 5: Mantener la ruta online corta
La solicitud pasa por limitación de tasa, normalización, resolución de configuración regional y una caché exacta de prefijos calientes. Un enrutador selecciona el shard de prefijo y la réplica. La réplica realiza una búsqueda en el índice, elimina las entradas del conjunto de denegación rápida, deduplica los IDs estables y devuelve los primeros 10. Ninguna consulta de registros sin procesar, agregación distribuida o clasificación completa pertenece a esta ruta.
Las claves de caché incluyen configuración regional, prefijo normalizado, límite, versión de política y versión del índice activo. Esto evita que una respuesta de ranking o política antigua sobreviva a la activación. Los prefijos vacíos y de un solo carácter se precomputan por separado porque su tráfico y conjuntos de candidatos son inusualmente amplios. El almacenamiento en caché negativo puede proteger contra prefijos inexistentes, pero su TTL no debe ocultar sugerencias recién elegibles más allá del objetivo de frescura.
Paso 6: Sharding por localidad y prefijos calientes
Particiona primero por configuración regional y luego por un rango de prefijos o hash de los primeros caracteres normalizados. Las particiones por rango preservan la localidad pero crean shards calientes; el hashing puro equilibra la carga pero puede requerir metadatos de enrutamiento adicionales. Un enrutador práctico posee un mapa versionado de rango de prefijo a shard y puede dividir un rango caliente, como un único primer carácter popular, sin reconstruir rangos no relacionados.
Replica cada shard a través de dominios de fallo y enruta a una réplica local saludable. Registra las QPS por prefijo, la tasa de aciertos de caché, el uso de CPU del shard, el p99 de búsqueda y los bytes del índice. Agregar réplicas resuelve la carga de lectura; dividir o aislar un rango caliente resuelve el sesgo. Si un shard no está disponible, devuelve una versión en caché con una métrica explícita de frescura o una lista vacía; nunca sugerencias de otra configuración regional.
Paso 7: Cumplir con dos relojes de frescura
El índice base se reconstruye cada 15 minutos. Una pequeña superposición (overlay) de tendencias recientes puede agregar una ventana más corta y fusionar un conjunto acotado con los candidatos base, pero debe pasar por los mismos filtros de privacidad y seguridad. Si esa superposición falla, sirve el último índice base bueno en lugar de dejar todo el endpoint no disponible.
Las eliminaciones por políticas utilizan un conjunto de denegación distribuido por separado con un objetivo de un minuto. Las réplicas de servicio filtran los IDs denegados después de la búsqueda, y las claves de caché incluyen su versión. La siguiente compilación base los elimina de forma permanente. Este diseño de dos relojes evita reconstruir un artefacto grande para una eliminación de emergencia mientras preserva la publicación base determinista.
Paso 8: Validar el ranking, la seguridad y las operaciones
Las pruebas de carga reproducen la distribución observada de longitud de prefijo y configuración regional a un pico de 150 000 QPS, incluidos prefijos calientes de un carácter, inicio con caché fría, pérdida de réplicas y activación de versiones. Asegura un p99 inferior a 50 ms en el límite del servicio, una tasa de error acotada, ausencia de sumas de comprobación mixtas por respuesta y recuperación sin estampida de solicitudes (thundering herd).
La evaluación offline cubre la relevancia de top-K, la cobertura, la tasa de duplicados, la corrección de configuración regional, el recall de contenido prohibido y la estabilidad entre versiones. Los experimentos online utilizan la compleción de búsquedas y la calidad de resultados posteriores con salvaguardas para la tasa de búsquedas sin resultados, latencia, quejas y concentración de exposición. Una mayor tasa de clics por sí sola es insuficiente porque la posición de visualización influye en los clics.
Los simulacros operativos incluyen un lote de eventos envenenado, una compilación fallida, un artefacto de tamaño excesivo, un shard caliente, un conjunto de denegación obsoleto, un despliegue parcial de réplicas y una regresión en el ranker. Cada alerta debe asociarse a una acción segura: pausar la activación, recurrir a la última versión buena, aislar la superposición, dividir el rango o activar la regla de denegación de emergencia.
Ejemplo de respuesta de alta calidad
“Comenzaría con compleción de prefijos anónima y específica por configuración regional, devolviendo diez resultados. A partir de 50 millones de usuarios, diez búsquedas y cinco solicitudes por búsqueda, obtengo 2500 millones de solicitudes al día, aproximadamente 28 900 QPS promedio. Planificaría la capacidad para el pico establecido de 150 000 y mediría el tamaño del índice serializado en lugar de adivinar la memoria del Trie.
La ruta de datos y la ruta de servicio están separadas. Los eventos de búsqueda completada ingresan a un flujo. La agregación produce recuentos de usuarios distintos y señales de recencia y calidad de resultados. Los candidatos pasan por filtros de frecuencia mínima, abuso, privacidad y moderación antes de que un ranker escriba una lista superior acotada por prefijo normalizado. Cada artefacto registra su marca de agua de datos y versiones de normalización, ranker y políticas.
Las réplicas de servicio mantienen versiones inmutables del índice. Cargan y validan una nueva versión junto a la anterior, luego el enrutamiento cambia de forma atómica y puede revertirse. Una solicitud normaliza el prefijo y la configuración regional, verifica una caché versionada, se enruta al shard de prefijo, realiza una búsqueda, aplica el conjunto de denegación rápida y devuelve diez. Los rangos calientes de un carácter obtienen caché dedicada y se pueden dividir de forma independiente.
La reconstrucción base cumple con el objetivo de 15 minutos. Una pequeña superposición de tendencias controlada puede mejorar la recencia, mientras que las eliminaciones de emergencia utilizan una capa de denegación de un minuto; cualquiera de las dos puede fallar sin corromper la última base buena. Probaría la distribución real de prefijos a 150 000 QPS y monitorearía p99, frescura, tasa de aciertos de caché, sesgo de shards, relevancia, fuga de configuración regional, recall de seguridad y tiempo de rollback.”
Errores comunes
- Consultar y ordenar registros sin procesar en cada pulsación de tecla → el trabajo crece con el historial y hace que la latencia de cola sea impredecible → precomputa listas top-K acotadas y mantén la búsqueda online acotada de forma constante.
- Llamar a la estructura de datos 'un Trie' y detenerse ahí → esto omite el ranking, la publicación, el sharding, la seguridad y la recuperación → describe tanto el ciclo de vida de construcción como el de servicio y evalúa representaciones.
- Estimar la RAM a partir de un tamaño de nodo inventado → la codificación y el uso compartido de prefijos determinan los bytes reales → serializa datos representativos y mide el tamaño del artefacto y la latencia de búsqueda.
- Almacenar en caché solo por prefijo → las configuraciones regionales, las políticas y las versiones de índice filtran o preservan resultados incorrectos → incluye en la clave todas las versiones que afecten al resultado.
- Publicar in situ → los lectores observan datos parciales o mixtos → construye artefactos inmutables, valida, carga en paralelo y activa atómicamente.
- Usar la popularidad como única regla de elegibilidad → puede surgir texto personal raro, manipulado o dañino → aplica umbrales de usuarios distintos y filtros de antiabuso, privacidad y moderación.
- Reconstruir todo para una eliminación de emergencia → el plazo de seguridad pasa a depender de un trabajo por lotes grande → distribuye una capa de denegación rápida y elimina permanentemente en la siguiente compilación base.
- Tratar el CTR (click-through rate) como relevancia sin sesgos → la posición mostrada influye en los clics → combina experimentos controlados con evaluaciones offline y métricas de seguridad.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cómo agregarías coincidencia difusa (fuzzy)?
Mantén la búsqueda de prefijo exacto como el primer generador económico. Activa la generación difusa solo después de una longitud mínima o cuando la cobertura exacta sea baja, limita la distancia de edición y el recuento de candidatos, y fusiona mediante un único ranker y política de moderación. Evalúa comparativamente la distancia consciente de Unicode y las entradas adversarias, ya que la expansión difusa aumenta el uso de CPU y puede recuperar variantes sensibles a las políticas.
Pregunta de seguimiento 2: ¿Cómo agregarías personalización?
Combina un pequeño conjunto autorizado de candidatos personales tras recuperar los candidatos globales. La caché permanece global hasta ese límite; las respuestas finales pasan a tener alcance de usuario y no deben ingresar a una caché compartida. Define consentimiento, retención, eliminación, exclusiones de consultas sensibles, tiempos de espera de características y un fallback exclusivo para resultados globales antes de agregar características de ranking.
Pregunta de seguimiento 3: ¿Qué pasa si una configuración regional ya no cabe en memoria?
Divide sus rangos de prefijos utilizando bytes y QPS medidos, luego actualiza el mapa de enrutamiento versionado. Mantén los prefijos calientes de nivel superior en réplicas dedicadas y permite que los rangos fríos usen un índice mapeado en memoria o remoto si su p99 aún cumple con el presupuesto. Rebalancea por versión de artefacto para que los lectores nunca dependan de una migración de claves in situ.
Pregunta de seguimiento 4: ¿Cómo admitirías noticias de última hora en cuestión de segundos?
No acortes toda la compilación base a ciegas. Agrega una superposición de streaming estrictamente acotada con fuentes de candidatos confiables, un umbral de elegibilidad alto, moderación inmediata, TTL y un interruptor de apagado de emergencia (kill switch). Fusiónala con los resultados base bajo un presupuesto fijo de candidatos. Si su frescura o marca de agua de política queda obsoleta, descarta la superposición y sirve la última base buena.
Pregunta de seguimiento 5: ¿Cómo eliminas una consulta tras una solicitud de privacidad?
Elimina o marca con tombstones los eventos sin procesar y agregados elegibles según el modelo de datos, agrega el ID de la sugerencia a la capa de denegación rápida, invalida las entradas de caché afectadas mediante la versión de política y reconstruye el artefacto base a partir de entradas corregidas. Audita el tiempo de propagación entre regiones sin volver a registrar el texto confidencial.