Plan
Es muy importante tenerlo. Incluso si comete un error en alguna parte y se equivoca en su razonamiento, el enfoque estructurado general jugará en sus manos. Al principio, puedes ser moderadamente contundente y preguntarle al entrevistado los detalles, pero a partir de cierto punto (que en mi plan a continuación corresponde al punto 3) debes tener la iniciativa por completo y es mejor no dejarla ir hasta el final. Mi plan era algo como esto:
- Reúna una lista de características clave y escríbalas en la esquina de la pizarra. Este sencillo truco le ayudará a recordar una restricción o suposición importante.
- Entender qué características técnicas debe tener el sistema: RPS esperado, rango de tiempos de respuesta aceptables, expectativas en términos de consistencia y confiabilidad.
- Cree la solución de una sola máquina más simple que de alguna manera funcione. No es necesario comenzar con 20 centros de datos en todo el mundo, es mucho mejor llegar gradualmente a esto.
- Encuentre un solo punto de falla o cuello de botella en el desempeño.
- Ofrezca una o más opciones para resolver el problema, explique claramente los pros y los contras de cada una de ellas
- Elija una de las opciones y vaya al paso 4, si aún queda tiempo, y si termina, pase al siguiente elemento
- Estime el tamaño del almacenamiento, la cantidad de servidores, el ancho de banda de la red, anótelo todo cuidadosamente
- Bonificación: hable sobre funciones adicionales, implementación de ML, métricas de productos, experimentos
El control del tiempo es muy importante. Intenté dedicar entre 5 y 10 minutos a los dos primeros puntos y 5 minutos a los dos últimos.
Compensaciones
Necesitan ser hablados, incluso si parecen obvios. Después de introducir cualquier parte nueva, es importante decir algo como "agregamos un nuevo elemento, esto resolverá tal o cual problema, pero pagaremos por esto". Las compensaciones pueden ser algo como esto:
- Cualquier componente nuevo del sistema o un aumento en la cantidad de repuestos existentes resuelve el problema de velocidad de carga / respuesta, pero agrega dolores de cabeza con el soporte y la implementación.
- La fragmentación resuelve las limitaciones de carga y espacio, pero añade problemas de fragmentación en el futuro.
- El almacenamiento replicado resuelve el problema de la carga y la confiabilidad, pero en el caso de las réplicas de lectura y escritura, te hace pensar en valores podridos y la oposición de disponibilidad y consistencia
- El caché resuelve el problema de carga, pero te hace pensar en valores rancios y coherencia del caché.
- Su propia solución se puede modificar y optimizar fácilmente para sus necesidades, pero primero debe escribirla.
- Lo bueno de la solución existente es que ya existe, pero tienes que averiguarlo.
Números
Todos conocen los números de latencia que todo programador debería conocer , pero los números en el enlace, en mi opinión, no están estructurados de la manera más conveniente y los reformateé en el proceso de preparación para facilitar la memorización.
En última instancia, lo siguiente es importante:
- Conozca el tiempo dedicado a leer datos de diferentes niveles de cachés de procesador, memoria, SSD, HDD y red.
- Recuerde el tiempo de los viajes de ida y vuelta dentro del centro de datos y alrededor del mundo, así como la latencia mínima que una persona percibe como retraso (~ 100ms).
- Para poder convertir rápidamente bytes a gigabytes, nanosegundos a segundos, etc., desarrollé esta habilidad por sí sola en el proceso de práctica.
Práctica
Compré una pizarra, tomé los servicios existentes y traté de averiguar cómo los haría desde cero. Dibujé diagramas en el tablero, calculé la carga y los recursos necesarios, busqué puntos débiles en mi diseño. También tengo grandes amigos con los que organizamos pseudo-secciones y nos entrenamos unos a otros; fue una experiencia muy gratificante. Después de la práctica, puede conectarse en línea y buscar cómo se hace realmente, y luego volver a intentarlo. Después de 10-20 rondas con diferentes servicios, la iluminación se establece y las partes recurrentes individuales en los sistemas existentes comienzan a ser claramente visibles. Las piezas de repuesto pueden ser, por ejemplo:
- Búsqueda (preferiblemente con la capacidad de actualizar el índice en tiempo real)
- (gfs, haystack)
- kv- (cassandra, dynamo)
- Message queue pub-sub (kafka)
- (twitter, instagram, facebook)
- , , - (whatsapp, telegram, battle.net)
- , - (skype, twitch, youtube)
- Grokking the system design interview. , , .
- System design primer. , .
- ( ). . , , .
- Una gran selección de alta escalabilidad
- Bueno, el recurso más importante son tus amigos y conocidos que saben cómo funcionan sus sistemas y pueden contarte sobre ellos.
Varios buenos videos y canales.
1. Escalabilidad
2. Introducción a la arquitectura y entrevistas de diseño de sistemas
3. Cuatro patrones arquitectónicos de sistemas distribuidos
4. Dropbox en 2012
5. Slack
6. Twitter
7. Reddit
8. Instagram
9. Youtube en 2007
10. Canal sobre diseño de sistemas de un compatriota
11 . otro canal
12. Y otro canal
Si no tiene un período de tiempo difícil, pero la perspectiva de una entrevista ya se vislumbra en el horizonte, la táctica más correcta sería leer / mirar constantemente algo en segundo plano sobre el tema de los grandes sistemas. Lo mismo ocurre con los acertijos algorítmicos: es mejor resolverlos periódicamente y estar siempre en buena forma que intentar dominar todo el código litigioso el fin de semana anterior a la entrevista. Sin embargo, la preparación intensiva para la sección de arquitectura en poco tiempo me convirtió en un especialista mucho mejor.