¿Cómo se puede diseñar un sistema distribuido a gran escala durante una entrevista? En los últimos 2 años, tomé cientos de entrevistas de diseño de sistemas y ayudé a los ingenieros a prepararse para sus entrevistas. Con base en esa experiencia, ideé un conjunto de pasos que son útiles para abordar un problema de entrevista de diseño de sistema. En esta publicación, me enfocaré en los siguientes temas: ¿Cómo prepararse para las entrevistas de diseño de sistemas? ¿Cómo abordar un problema de manera sistemática para maximizar sus posibilidades de éxito? EDITAR: Consulte también . las 10 preguntas principales de entrevistas de diseño de sistemas para ingenieros de software Anteriormente escribí un par de publicaciones de blog que enumeran los errores comunes en la programación de entrevistas: cómo no y diseñar Netflix en su entrevista de diseño de sistema de 45 minutos cómo no tener éxito en su entrevista de codificación de 45 minutos . Recibí muchos comentarios (y correos electrónicos) en mis publicaciones anteriores. La pregunta más común fue cómo debería un entrevistado abordar las entrevistas de diseño del sistema. Hay tantos conceptos, direcciones, componentes, pros y contras que uno no puede describirlos todos en 4 horas, mucho menos en 45 minutos. A diferencia de las entrevistas de codificación de pizarra, hay muy pocos momentos "Ajá" en las entrevistas de diseño de sistemas. En otras palabras, las entrevistas de diseño de sistemas se tratan menos de tener suerte y más de hacer el trabajo duro de obtener conocimiento. Al final, su desempeño en estas entrevistas depende de los siguientes 2 factores. Su conocimiento, obtenido ya sea a través del estudio o de la experiencia práctica. Su capacidad para articular sus pensamientos. Cuando las empresas hacen preguntas de diseño, quieren evaluar sus habilidades de diseño y su experiencia en el diseño de sistemas distribuidos a gran escala. Lo bien que lo haga en tales entrevistas a menudo dicta su nivel de contratación (y en algunos casos incluso el salario). Por lo tanto, le conviene tener un plan y prepararse para estas entrevistas. Si está buscando recursos para prepararse para entrevistas de diseño y programación de sistemas, eche un vistazo a: Grokking la entrevista de diseño del sistema Grokking la entrevista de diseño orientado a objetos Coderust 3.0: preparación de entrevistas de codificación más rápida con visualizaciones y desafíos interactivos Estructuras de datos para codificar entrevistas 7 pasos para abordar una Entrevista de Diseño de Sistemas Como está estudiando, aquí hay un marco de 7 pasos que recomiendo para abordar cada problema. Para mantener la realidad de los ejemplos, elegiremos una pregunta común en las entrevistas: y vea cómo se puede aplicar cada paso para diseñar Twitter. diseñe un servicio escalable como Twitter Paso 1: Recopilación de requisitos: Muchos candidatos piensan que las entrevistas de diseño del sistema tienen que ver con la "escala", olvidándose de poner el énfasis requerido en la parte del "sistema" de la entrevista. Debe tener un "sistema" que funcione antes de poder escalarlo. Como primer paso en su entrevista, debe hacer preguntas para encontrar el alcance exacto del problema. Las preguntas de diseño son en su mayoría abiertas y no tienen UNA respuesta correcta. Es por eso que es fundamental aclarar las ambigüedades al principio de la entrevista. Los candidatos que dedican tiempo a definir claramente los objetivos finales del sistema, siempre tienen más posibilidades de éxito. Aquí hay algunas preguntas para diseñar Twitter que deben responderse antes de pasar a los siguientes pasos: ¿Quién puede publicar un tuit? (respuesta: cualquier usuario) cualquier usuario, ya que todos los tweets son públicos_)_ ¿Quién puede leer el tuit? (respuesta: ¿Un tweet contendrá fotos o videos? (respuesta: por ahora, solo fotos) ¿Puede un usuario seguir a otro usuario? (respuesta: sí). ¿Puede un usuario dar "me gusta" a un tweet? (respuesta: sí). Lo que se incluye en el feed del usuario (respuesta: tweets de todos los que estás siguiendo). ¿El feed es una lista de tweets en orden cronológico? (respuesta: por ahora, sí). ¿Puede un usuario buscar tweets (respuesta: sí)? ¿Estamos diseñando la interacción cliente/servidor o la arquitectura backend o ambas? (respuesta: queremos entender la interacción entre cliente/servidor pero nos enfocaremos en cómo escalar el backend). Cuántos usuarios en total hay (respuesta: esperamos llegar a 200 millones de usuarios en el primer año). Cuántos usuarios activos diarios hay (100 millones de usuarios inician sesión todos los días) Si notas, algunas de estas respuestas no son exactamente similares al Twitter real, y está bien. Es un problema hipotético orientado a evaluar su enfoque. Solo está haciendo estas preguntas para analizar el problema que va a resolver hoy. por ejemplo, ahora no tiene que preocuparse por manejar videos o generar una línea de tiempo usando algoritmos, etc. Paso 2: Definición de la interfaz del sistema Si ha reunido los requisitos y puede identificar las API expuestas por el sistema, ha terminado en un 50 %. Defina qué API se esperan del sistema. Esto no solo establecería el contrato exacto que se espera del sistema, sino que también garantizaría que no se haya equivocado en ningún requisito. Algunos ejemplos de nuestro servicio similar a Twitter serían: postTweet (user_id, tweet_text, image_url, user_location, timestamp , ... ) Paso 3: Estimación de la capacidad al dorso del sobre Siempre es una buena idea estimar la escala del sistema que va a diseñar. Esto también sería útil más adelante cuando se centre en escalar, particionar, equilibrar la carga y almacenar en caché. Qué escala se espera del sistema (por ejemplo, número de tweets nuevos, número de vistas de tweets, cuántas generaciones de línea de tiempo por segundo, etc.) ¿Cuánto espacio de almacenamiento necesitaríamos? ¿Esto dependerá de si los usuarios pueden subir fotos y videos en sus tweets? ¿Qué uso de ancho de banda de red esperamos? Esto sería crucial para decidir cómo gestionaríamos el tráfico y equilibraríamos la carga entre servidores. Paso 4: Definición del modelo de datos La definición temprana del modelo de datos aclarará cómo fluirán los datos entre los diferentes componentes del sistema. Más tarde, lo guiará hacia una mejor partición y administración de datos. El candidato debe poder identificar varias entidades del sistema, cómo interactuarán entre sí y los diferentes aspectos de la gestión de datos como el almacenamiento, la transferencia, el cifrado, etc. Aquí hay algunas entidades para nuestro servicio similar a Twitter: ID de usuario, nombre, correo electrónico, fecha de nacimiento, datos de creación, último inicio de sesión, etc. Tweet, contenido, ubicación de Tweet, número de Me gusta, marca de tiempo, etc. Usuario: Tweet: ID de ¿Qué sistema de base de datos debemos utilizar? ¿NoSQL como Cassandra se adapta mejor a nuestras necesidades, o deberíamos usar una solución similar a MySQL? ¿Qué tipo de almacenamiento de blobs deberíamos usar para almacenar fotos y videos? Paso 5: diseño de alto nivel Dibuje un diagrama de bloques con 5 o 6 cuadros que representen los componentes centrales de su sistema. Debe identificar suficientes componentes necesarios para resolver el problema real de principio a fin. Para Twitter, en un nivel alto, necesitaríamos múltiples servidores de aplicaciones para atender todas las solicitudes de lectura/escritura con balanceadores de carga frente a ellos para la distribución del tráfico. Si asumimos que tendremos mucho más tráfico de lectura (en comparación con escritura), podemos decidir tener servidores separados para manejar lecturas y escrituras. En el backend, necesitamos una base de datos eficiente que pueda almacenar todos los tweets y pueda admitir una gran cantidad de lecturas. También necesitaríamos un sistema de almacenamiento de archivos distribuido para almacenar fotos (y videos) y un índice de búsqueda e infraestructura para permitir la búsqueda de tweets. Paso 6: Diseño detallado para componentes seleccionados Profundice en 2 o 3 componentes; Los comentarios de los entrevistadores siempre deben guiarlo hacia qué partes del sistema quiere que explique más. Debería poder proporcionar diferentes enfoques, sus pros y sus contras, y ¿por qué elegiría uno? Recuerde que no hay una respuesta única, lo único importante es considerar las compensaciones entre las diferentes opciones teniendo en cuenta las limitaciones del sistema. p.ej Dado que almacenaremos una gran cantidad de datos, ¿cómo debemos particionar nuestros datos para distribuirlos en varias bases de datos? ¿Deberíamos intentar almacenar todos los datos de un usuario en la misma base de datos? ¿Qué problemas puede causar? ¿Cómo manejaríamos a los usuarios de alto tráfico, por ejemplo, celebridades que tienen millones de seguidores? Dado que la línea de tiempo del usuario contendrá los tweets más recientes (y relevantes), ¿deberíamos tratar de almacenar nuestros datos de una manera optimizada para escanear los tweets más recientes? ¿Cuánto y en qué capa deberíamos introducir caché para acelerar las cosas? ¿Qué componentes necesitan un mejor equilibrio de carga? Paso 7: Identificar y resolver cuellos de botella Trate de discutir tantos cuellos de botella como sea posible y diferentes enfoques para mitigarlos. ¿Hay algún punto único de falla en nuestro sistema? ¿Qué estamos haciendo para mitigarlo? ¿Tenemos suficientes réplicas de los datos para que, si perdemos algunos servidores, aún podamos atender a nuestros usuarios? Del mismo modo, ¿tenemos suficientes copias de diferentes servicios en ejecución, de modo que algunas fallas no provoquen el apagado total del sistema? ¿Cómo estamos monitoreando el desempeño de nuestro servicio? ¿Recibimos alertas cada vez que fallan los componentes críticos o su rendimiento se degrada? En resumen, debido a la naturaleza no estructurada de las entrevistas de diseño de software, los candidatos que están organizados con un plan claro para atacar el problema tienen más posibilidades de éxito. Una vez más, si está buscando recursos para prepararse para entrevistas de diseño y programación de sistemas, eche un vistazo a: Grokking la entrevista de diseño del sistema Coderust 3.0: preparación de entrevistas de codificación más rápida con visualizaciones y desafíos interactivos Estructuras de datos para codificar entrevistas ¡Feliz entrevista! Si te gustó esta publicación, haz clic en el signo 💚 y sígueme para más publicaciones. Si tienes algún comentario, comunícate conmigo en Twitter . Fahim es el co-fundador de Educativa . Estamos construyendo la plataforma de aprendizaje interactivo de próxima generación para ingenieros e instructores de software. Los estudiantes aprenden a través de cursos interactivos. Los instructores pueden crear y publicar rápidamente cursos interactivos utilizando nuestro creador de cursos. Si está interesado en publicar cursos o saber más, no dude en comunicarse.
