Preparación para la entrevista de diseño de sistemas

1. ¡Bienvenido a esta clase!: Hola chicos y bienvenidos a este curso de preparación para la entrevista de diseño de sistemas. Mi nombre es Alex y soy ingeniero de software, la prueba que se está tomando y también dando entrevistas de System Design durante mi tiempo en empresas de software. Cuando me enteré de la posibilidad de crear un curso para explicar más sobre estas complejas entrevistas tipo II estaba bastante ansioso por desarrollar una. Esta clase se estructurará en cuatro lecciones que contienen pasos prácticos para que usted tome con el fin de entender exactamente lo que los entrevistadores esperarán con interés a la hora de programar estos tipos de entrevista que primero evolucionarás, presentarte qué es el diseño del sistema. Y luego veremos la plantilla que funciona a la hora resolver cualquier pregunta de entrevista de diseño de sistema. Después de esto, también resolveremos dos de las preguntas de entrevista más comunes desde este campo, diseñando una nueva URL, servicio de acortamiento, y el sistema de intercambio de fotos. Si estás interesado en perfeccionar tus habilidades de entrevista de ingeniero de software, considera este curso para ti. No hay otros requisitos entonces una conexión a Internet S para el proyecto de esta clase, será extremadamente práctico y te implicará seguir los pasos presentados en la plantilla del curso. Para que puedas comenzar en tu viaje de resolver preguntas de entrevista de diseño de sistemas. Pensamos lo dicho, creo que estamos listos. Nos vemos en la primera lección. 2. ¿Qué es el diseño de sistemas?: Hola chicos y bienvenidos de nuevo al sistema. ¿ Le contaste tutorial entrevistado. En esta conferencia vamos a discutir qué es exactamente el diseño de sistemas, lo que se supone que es una entrevista de diseño de sistemas. También vamos a echar un vistazo a algunas buenas prácticas generales cuando se trata de su propia entrevista de diseño de sistemas. Es posible que los esté ejecutando en posición donde está tratando conseguir un trabajo para una empresa de ingeniería de software. Y escuchaste a los dos, voy a tener una entrevista de diseño de sistemas junto con las entrevistas más orientadas a técnicas donde realmente se supone que debes cubrir. Bueno en general, en las entrevistas de diseño de sistemas, realmente no se te permite pelar. Quizás solo un poquito para probar tus puntos en algunas partes. Ahora, comenzar con la definición de qué exactamente el sistema diseñó facilidad. Es sólo el proceso de definición de diferentes módulos, interfaces, componentes, y también los datos para que un sistema cumpla requisitos especificados que podrían especificarse en su pregunta que obtenga un más nuevo en entrevista. Ahora, el proceso de desarrollo de sistemas es en realidad el proceso que vas a estar haciendo en tu trabajo. Si aterrizas la posición de desarrollador, donde realmente vas a crear o alterar el sistema. Junto con los procesos, modelos, metodologías, y también prácticas que se utilizan para desarrollarlos. Pero por ahora, el diseño del sistema es solo el proceso de definición de los componentes. Por lo que básicamente se trata de hablar de lo que se necesitaría al intentar pensar en desarrollar un proyecto desde cero. Llegar a la entrevista aparte esta entrevista de diseño de sistema que de nuevo, podría haber realizado con el único propósito de permitir los candidatos que lo están tomando. Como tal vez programadores, pero también pueden ser ingenieros o diseñadores. La oportunidad de demostrar su pericia en el campo al que están solicitando. El uso tangible del conocimiento en solución de un problema real que la empresa podría estar enfrentando. Entonces estos son de nuevo, problemas muy grandes y generales también. Por lo que se te va a pedir que implemente algo así como un chat de WhatsApp o algo así. Vamos a tener también ejemplos concretos más adelante en este curso. Pero de nuevo, son grandes problemas y hay que hablar de ellos y pensar en cómo los implementaría de manera óptima tanto desde el punto de vista de la complejidad del tiempo como del espacio. Ahora, esta entrevista de diseño de sistemas también se realiza posteriormente en el proceso de entrevista. En primer lugar, es posible que esté obteniendo una entrevista técnica donde realmente se le pide que codifique un problema real. Y luego más tarde en el proceso de entrevista, justo para DC, tienes conocimiento previo de algunos temas y también puedes ver las cosas desde una perspectiva más grande. También te van a dar la entrevista de diseño de sistemas. Ahora, este juicio pretendía que sea ver qué tan bien se trabaja en un equipo. Y también eres acercamiento a una solución de problemas usando preguntas que son, como mencioné anteriormente, de composición abierta. Y solo necesitas llegar a la mejor solución posible. Se supone que esta entrevista analiza tu procesamiento, resolviendo los problemas, tu proceso de pensamiento en la creación y también el diseño de los sistemas para ayudar a eventuales clientes que firma quieres entrar necesidades. También es una oportunidad para que muestres al personal contratante, ya sea al gerente u otros desarrolladores con los que te estás tomando esta entrevista. Los dos son valiosos el miembro, al mostrar sus habilidades de esta manera. Cuando se trata de entrevistar preguntas y respuestas en el diseño de sistemas, suelen ser muy ambiguas. Y esto es sólo para permitir la oportunidad de demostrar sus calificaciones. Pero no es necesario apresurarse a dar una respuesta que pueda estar equivocada o ni siquiera equivocada, pero no lo suficientemente documentada. También se reúne para hacer preguntas antes responder a su pregunta sólo con el fin de reducir el alcance. Dale una dirección para aclarar también las explicaciones. Esto fue sobre ello para una presentación general de una entrevista de diseño de sistemas. En la siguiente conferencia, vamos a discutir un poco cómo podemos abordar cada pregunta de entrevista de diseño de sistemas. Hay un proceso de cuatro pasos que se ha documentado para estar funcionando, dando vueltas para echar un vistazo a eso también. Pero por ahora muchas gracias por seguir conmigo hasta el final de esta conferencia. Y espero veros chicos en la siguiente. 3. Una plantilla para cualquier pregunta: Hola chicos y bienvenidos de nuevo al tutorial de entrevista de diseño del sistema. En esta conferencia, vamos a echar un vistazo a unos pasos que podríamos utilizar en una plantilla cuando se nos da pregunta de diseño de sistema en una entrevista. Este temporal el tiempo a punto de hablar es de una talla única se adapta a todo tipo de plantilla cuando se trata de preguntas de entrevista de diseño de sistema, solo hay unos pasos que necesitas para asegurarte de que se obtiene a través al responder a la pregunta de la entrevista de diseño del sistema. Así que al empezar con esta plantilla, lo primero que hay que compartir al ser hecho la pregunta es que la comprendas plenamente. Por lo que necesitamos entender este problema. Necesitan que resuelvas y establezcas el alcance del diseño del que vas a hablar. Esta es la parte donde necesitas hacer preguntas justo después de t te dio los detalles completos sobre las preguntas. Y también necesitarás establecer cualquier limitación que pueda aparecer. No es necesario apresurarse a tratar de resolver el problema antes de tener todos los hechos y tener otras cosas que podrían no estar claras para usted despejadas por el entrevistador. El siguiente paso sería proponer un diseño de alto nivel. Digo dicho, no es necesario saltar a la implementación sin confirmarlo. El enfoque en el que estás pensando en realidad está satisfaciendo todas las limitaciones que quieren. Por lo que podría proponer un enfoque que considere que es el mejor para resolver el problema de diseño del sistema. Ve cómo reaccionan a tu enfoque antes de saltar a implementar realmente donde incluso ir más allá en detalles en cada parte de tu propuesta. Ahora la tercera parte en realidad se hace más tiempo que consume el modo, que es el diseño Deep Dive. Esto sucede una vez que validó con su entrevistador que está en el camino correcto, ya sabe esto, en este punto, sólo tiene que entrar en todos los detalles de la aplicación resolviendo que se te ocurrió. Y esta es la parte donde se necesita tener una comprensión profunda y vocabulario del diseño de sistemas. Y en este diseño de inmersión profunda, hay muchos pasos de nuevo, y comenzando a profundizar. La primera pregunta que debes hacer son los requisitos. Y los requisitos podrían ser funcionales o no funcionales. Los requisitos funcionales son solo funcionalidades que el problema que estás resolviendo está brindando a los usuarios. Entonces por ejemplo, en tus redes sociales, hay una funcionalidad que te puede gustar un post de cualquier otro usuario. Ese es un requisito que es funcional. Es necesario establecer y ejecutar a través todos los requisitos funcionales con sus entrevistadores por curso, enumerarlos y validar su importancia. Ahora, los requisitos también pueden ser no funcionales, y aquí podrían haber algunas cosas como la latencia, que es el tiempo de respuesta de la interacción del usuario. Fiabilidad, lo que significa que no habrá pérdida de datos. La consistencia, lo que significa que alta disponibilidad. Ahora dos cosas que también debes tener en cuenta al intentar diseñar tus componentes. Necesitas hacerlos. En primer lugar, tolerante a fallas, lo que significa que su sistema está en funcionamiento en todo momento, pesar de que podría haber algunos errores o algún rasguño de base de datos. Y también necesitan ser enfermedad escalable. Otro hecho importante, escalable solo significa que necesitas manejar la creciente cantidad de tráfico en tu sistema. Ir. Además, a la segunda parte de este diseño Deep Dive. Aparte de requisitos, también necesitas hacer una estimación de almacenamiento basada en la modalidad de datos, solo necesitas dar una estimación aproximada de la cantidad de datos que se deben almacenar. Además, es necesario pensar en el número de solicitudes, el servicio que presta y la relación de lectura-escritura. Después de que hablaste de todas estas estimaciones de almacenamiento, debes pensar en un diseño de base de datos. Aquí, se están llevando a cabo las acciones que usted es usuario puede realizar para interactuar con su sistema. También puedes pensar aquí qué tipo de base de datos utilizarás y también por qué puedes ir por SQL, NoSQL, y así sucesivamente. Solo necesitas discutir sobre cada opción y pensar en cuál se ajusta mejor a tu solución. Entonces un cuarto paso sería iniciar un diseño básico de alto nivel, donde se pueda escribir sobre los clientes, los servidores, y también la base de datos. Y a partir de ese diseño básico, además se puede entrar en algunos detalles más y aislar los servicios, particionar los datos hablados sobre el almacenamiento en caché y también la replicación de los servicios y bases de datos, incluso equilibrio de carga y colas de mensajes. Si eso se ajusta a tu problema específico. Por supuesto hay opcionales en qué otras cosas que puedes pensar dependiendo exactamente del problema que te den, que puede ser el cifrado de algunos mensajes o contraseñas. Alguna telemetría que se asegura de realizar un seguimiento de las cosas que más se acostumbran en su aplicación. Algunos API gateway service discovery y también d servicio de analítica que analiza las solicitudes y la beta de usuario. Y después de este diseño deep dive, el último paso, hay que dar esto para simplemente envolver, lo que significa que con el diseño dado para, para construir. Si parece sensato, se puede pensar en identificar algunos cuellos de botella y áreas de mejora y hablar un poco sobre esos. Esta es la estructura general que debes tener en cuenta antes iniciar tu entrevista de diseño de sistemas sin siquiera que se le dé el problema. En algunas conferencias futuras, vamos a echar un vistazo a preguntas específicas de la entrevista de diseño del sistema como diseñar el pequeño sistema de URL, motores de búsqueda, unidades compartidas, y así sucesivamente celular que puede ver cómo aplico todos estos pasos desde esta plantilla exacta, mi enfoque a la hora de resolver problemas de DC. Si eso te suena interesante, espero verte en las próximas conferencias. Muchas gracias por quedarse conmigo hasta el final de éste. 4. El servicio de acortado de URL: Hola chicos y bienvenidos de nuevo al tutorial de entrevista de diseño del sistema. En esta conferencia, vamos a discutir famoso problema que a menudo se da en este tipo de entrevistas. Y más específicamente, el diseño de un nuevo servicio de acortamiento de URL. Al igual que por ejemplo, es posible que haya visto diminuta URL punto L y así sucesivamente. En esta conferencia, voy a repasar todos los aspectos que debes considerar cuando S lleva este tema en una entrevista de diseño de sistemas. Y después de ver esta conferencia, vas a saber cómo as esta pregunta. Pero no solo eso, también sabrías cómo puedes abordar estudios de problemas similares. Porque al resolver este problema, también vamos a respetar la plantilla que debemos usar en cualquier pregunta de diseño de entrevista de sistema que se nos dé. Comenzando con este problema de entrevista, necesitamos diseñar, como dije, un servicio de acortamiento de URL, como diminuta URL. Y esta superficie proporcionará, por supuesto, lisis corta, roja dirigiendo URL demasiado largas. Ahora, la dificultad de la entrevista de diseño de sistemas es bastante básica y suele ser la más dada en la entrevista de diseño de sistemas. Por lo que es muy importante que sepas resolver este problema. Lo primero que tenemos que discutir es ¿por qué necesitamos acortar la URL? Aquí hay múltiples razones y por qué necesitaríamos eso. En primer lugar, ahorran mucho espacio cuando se muestran, predicen el mensaje, y así sucesivamente. Y además si quieres escribirlos desde tu propio teclado, eres menos propenso a cometer errores al escribirlos. También se utiliza para optimizar los enlaces a través dispositivos y medir el rendimiento en los anuncios. Lo segundo que debemos abordar son los requisitos y los objetivos de nuestro sistema que necesitamos diseñar. Cuando se le da esta pregunta, les recuerdo aquí que cuando se encuentra en una pregunta de entrevista de diseño de sistema, así como otros tipos de entrevistas. Y se te está dando pregunta. Es necesario aclarar todos los requisitos al principio. Antes de tratar de responder a tu problema. Es necesario hacer llamado la pregunta para encontrar el alcance exacto del sistema que usted es entrevistador tiene en mente, yendo a las funcionalidades que esta pequeña superficie URL debe proporcionar a los usuarios finales de deber. Los tenemos divididos en las dos principales categorías de requisitos, que son funcionales y no funcionales. Al pensar en los requisitos funcionales, podemos pensar en dar una URL a nuestro servicio y poder generar de nuevo un más corto y único. Y a esto se le llama el eslabón corto. Este enlace que nuestro servicio brinda también debe ser lo suficientemente corto como para ser fácilmente copiado y pegado. Y vamos a discutir más adelante qué significa lo suficientemente corto y también acordamos ese término. Ahora el segundo requisito funcional puede ser que el usuario pueda escoger una costumbre en breve para sus URL. Entonces si no quieren uno generado aleatoriamente por nuestra superficie, también deberían poder escoger uno propio. Estos eslabones que nuestra superficie proporciona también deben tener un intervalo de tiempo después de la muerte. Deberían eliminarse y también caducar. Porque de lo contrario nuestra base de datos se desbordaría en algún momento si siguieras teniendo estos enlaces en ella. Por último, el acceso de los usuarios a un enlace corto debe por supuesto leer dirigido al enlace original que representa el enlace corto. También hay algunos requisitos no funcionales para el servicio de acortamiento de URL, que sería que la dirección roja debería ocurrir en tiempo real sin latencia alguna. Porque imagina que querrías hacer clic un poco punto L-Y link y tardará una eternidad en cargarse. Eras enlace real al que quieres acceder que no sería bueno en absoluto. Y también molesto. También otro requisito no funcional sería que el enlace abreviado que se proporciona no debe ser conjeturable o predecible en absoluto por un eventual usuario malicioso. Los últimos y más importantes requisitos no funcionales. Sería que nuestro sistema, nuestro servicio debería estar altamente disponible. Porque si fuera abajo, toda la redirección URL es que realizaría sería por supuesto, abajo con ella. Algunos requisitos adicionales aquí no pueden ser que nuestro servicio deba ser accesible para las API. Por lo que los terceros pueden hacer solicitud real a nuestros puntos finales y obtener en URL acortada unasolicitud real a nuestros puntos finales y obtener en URL acortadade nuevo como respuesta si la solicitud está bien. También algunas analíticas que podremos hacer con ese limonero. Y deben preocuparse cuantas veces ocurrió la Resurrección y también Cuanto más a menudo donde la dirección se enlaza, acceso y cosas por el estilo. Después de discutir todos estos requisitos y costos del sistema, podemos pasar a la tercera, que es la estimación de la capacidad que debe tener el servicio y también la restricción para vencer. Entonces cuando pensamos el servicio que vamos a implementar, por supuesto se leerá pesado. Eso se debe a que estarán disponibles muchas solicitudes de dirección roja en comparación con el nuevo acortamiento de URL. Y podemos asumir aproximadamente 90 a una relación entre leer y escribir. Porque si lo piensas, solo generas el enlace una vez, pero por supuesto sería leído mucho más de una vez. Ahora las estimaciones de tráfico para el servicio, podemos suponer que vamos a tener por encima 100 o 500 millones de nuevos acortamiento de URL por mes que se crean. Por lo que 500 millones de URLS siendo tal vez el servicio de torre. Con nuestro por ciento de readwrite, podemos esperar cerca de 50 mil millones de erecciones rojas durante este mes. También podemos pensar en consultas por segundo para nuestro sistema solo con el fin de que nuestra base de datos vea de estrellarse. Pero aparte de eso, también tenemos que mirar las estimaciones de almacenamiento. Aquí podemos volver a hacer estimación. Suponga que almacenamos todas las solicitudes de acortamiento de URL durante cinco años. Ya que tenemos 500 millones de nuevas URLs y objetos B y D que esperamos almacenar van a ser de unos 30 mil millones. Y asumiendo que tardaron unos 400 a 500 bytes cada uno, vamos a necesitar aproximadamente 15 terabytes para almacenar todos nuestros datos. También tenemos que pensar en las estimaciones de ancho de banda, no solo en la estimación de almacenamiento para la derecha, podemos esperar alrededor de 200 a 300 nuevas URL cada segundo. Y eso es por supuesto un top. Vamos a mirar lo más alto de esta gama. Por lo que el total de datos entrantes para nuestro servicio serían unos 500 bytes por solicitud veces dos o 300 nuevas URL y B segundo, lo que alrededor de 100 a 200 kilobytes por segundo. Una solicitud de lectura. Ya que cada segundo esperamos alrededor de 20 a 30 mil URL ya dirige el total de datos salientes va a ser de unos diez megabytes por segundo. También podemos mirar alguna estimación de memoria. ¿ Y si queremos atrapar algunas de nuestras URL cortas más utilizadas que son muy SH dijo x Bueno, podemos mirar un poco a la regla 8020. Es decir que el 20% de nuestras URLs van a generar el 80% del tráfico. Por lo que el 20% de nuestras URL cortas generadas van a ser las calientes. Y al corto vistazo, podemos ver que si tenemos 20 a 30 mil solicitudes por segundo, vamos a conseguir alrededor de 1.7 a 8 mil millones de solicitudes por día. Para atrapar el 20% de estos, vamos a necesitar aproximadamente 170 gigabytes de memoria. Como han visto en mi enfoque, la parte de la estimación de la capacidad y las limitaciones necesitan ser muy sencillas al pensar en el límite y estimar cuánta capacidad real y ancho de banda va a ser tomado por superficie implementada. Dije que también podemos mirar algunas APIs y discutir esta parte. Podemos poner a disposición algunos endpoints que nuestro servicio va a brindar para terceros que querían acceder a nuestro servicio display, hacer solicitudes a nuestros endpoints y volver como un responde la URL acortada. Entonces, por ejemplo, podemos tener un punto final que oriente llamó crear la URL. Y puede tomar la URL original como parámetro de cadena, que es por supuesto la URL original que desea haber acortado. Y también algún tipo de clave que se asocia con la clave de desarrollador API de una cuenta. Entonces sabemos quién está haciendo estas solicitudes y tenemos algún tipo de seguridad en estas partes. Como dije antes, este punto final, por supuesto devolveríamos la inserción exitosa. Por supuesto devolvería una cadena con la URL acortada si se realiza la solicitud. Bueno, y si no, tal vez un código de error, también podemos tener un endpoint de URL de eliminación. Lo que eso es importante, también puedes mencionarlo en cualquier cosa. También tenemos que pensar en cómo prevenir el abuso aquí. Si exponemos una API porque un usuario malicioso podría sacarte del negocio y destruir tus servicios si ponen alguna URL olive t es el diseño actual y llenar tu base de datos. Podemos imponer aquí algún límite a la clave de desarrollador API. Se puede limitar a un cierto número de creaciones de URL que dicen diez o 20 días o algo así. Ahora el siguiente paso sería pensar en el diseño y esquema de la base de datos. Definir el esquema en las primeras etapas de la entrevista realmente te ayudaría a entender el flujo entre los componentes, te guiaría hacia la posterior partición de los datos. Ahora algunas observaciones aquí serían que necesitamos almacenar para los servicios miles de millones de registros. Vamos a tener mucha URL acortada. Pero estos objetos van a ser muy pequeños, como ya he dicho, 500 kilobytes. No hay relaciones entre los registros. Por lo que aparte de almacenar qué usuarios crearon esa URL, eres más o menos libre de hacer lo que queramos aquí. Y otra observación respecto al diseño de la base de datos y relevante aquí es que nuestro servicio va a ser muy pesado en la parte roja. Vamos a necesitar, como dije, dos tablas, una para almacenar la información sobre las asignaciones de URL, y una para los datos del usuario, quien creó el enlace corto. Ya que anticipamos almacenar muchas filas. Y tampoco necesitamos mantener ninguna relación entre objetos. Ahora SQL tipo de elección sería muy buena aquí ya que también es muy fácil de escalar. Para que podamos mirar algo así como Dynamo DB. Vine aquí mientras usted resuelve, necesitamos crear el esquema de base de datos en una entrevista y también pensar qué tipo de base de datos se debe utilizar y además sugerir uno desde su propio conocimiento. El sexto paso aquí va a ser el diseño y algoritmo básico del sistema. Por lo que aquí vamos a entrar en realidad en la implementación de cómo va a funcionar nuestro servicio detrás de escena. El problema que estamos resolviendo aquí es generar la clave única acortada que se va a mapear a una URL SIC mayor y más grande dada. Esta situación, tenemos dos enfoques. Podemos generar estas claves de línea con un servicio de generación clave. Y va a generar seis cadenas aleatorias de letras antemano y almacenarlas en nueva base de datos. Siempre que queramos acortar aquí la URL, podemos tomar una que ya se genera por la superficie y años ella. Este enfoque es muy sencillo y rápido, pero porque no estamos codificando la URL, por lo que no necesitamos preocuparnos por la duplicación o las colusiones. El servicio de la generación clave va a asegurarse de que todas las claves van a ser únicas. También tenemos que tener en cuenta algunos problemas de concurrencia aquí, pues en cuanto se utilice una clave, se debe marcar en nuestra base de datos para asegurarnos de que vea que no se va a utilizar de nuevo. Y si hay múltiples servidores que están leyendo estas claves al mismo tiempo, podría obtener un escenario en el que dos o más servicio intentaron leer desde la base de datos, aunque de arriba al servicio puntos finales, sería muy menos probable. Ahora los servidores pueden utilizar estos sistemas de generación para leer y marquesinas en una base de datos. Y pueden usar dos mesas para almacenar las llaves. Una para las claves reales que aún no se utilizan, y otra para las claves que ya se utilizan. Y tan pronto como este servicio de generación le dará la clave a uno de los servidores, comerlos y moverlos a la mesa. Tenemos que pensar también aquí, si nuestro sistema de generación, siendo el sistema único de todo nuestro servicio, ¿no sería malo si moriría? Y ese es un punto muy bueno porque necesitamos tener una réplica en espera, este sistema de generación con el fin de tener un servidor de espera que pueda hacerse cargo para generarlas proporcionar fácil en caso de que algo le pasa a uno primario. Ahora, otro acercamiento aquí, otra degeneración muerta de las llaves con el servicio. También es codificar la codificación URL real. puede hacer una URL real calculando un hash único. O si estamos hablando del tiro 250 asientos o de los cinco vacíos, y podemos hash la URL dada con estos algoritmos, estos hashes se pueden codificar para su visualización. Y una pregunta razonable en este enfoque sería, ¿cuál sería el tamaño de la clave taquigráfica? Pueden ser de seis hasta 20 caracteres pares, pero eso sería una llave bastante larga. Podemos usar codificación base 64. Y si vamos a utilizar seis teclas largas de letra, entonces va a llevar alrededor de 64 a la potencia de seis posibles cuerdas. Si generáramos ocho letras llaves largas, vamos a tener cerca de 280 billones de posibles cadenas. Pero para nuestro sistema, el número de letra sería bastante alto. Y podemos suponer que seis letras pueden bastar para nuestro número de URLs. Ahora si usamos el algoritmo MD5 como nuestra función hash, por supuesto proporcionará, como ya sabrás, valores hash de 128 bits. Después de la codificación base-64, obtendremos cadena que tiene más de 21 caracteres. Ahora sólo tenemos espacio para seis u ocho caracteres por tecla corta. ¿ Cómo elegiremos entonces nuestra llave? Bueno, podemos tomar las primeras letras, pero esto puede resultar en duplicación de claves. Y para resolver eso, podemos optar por poner algunos otros personajes fuera de la codificación o intercambiar entre ellos para evitar este problema por completo. También podemos, después de dar la solución en una entrevista, pensar en algunos temas con nuestra solución, es que puede resultar no ser a prueba de balas y estos diferentes temas vienen de ti y no del entrevistador. Probablemente vas a conseguir puntos extra a medida que resulta ser un empleado eventual más consciente. Los diferentes tejidos con la codificación de una URL real usando un hashtag. La solución única puede ser que si varios usuarios ingresan la misma URL, pueden obtener la misma URL acortada. El problema de concurrencia es que fue el caso B, el último enfoque también. Pero aquí hay otro. ¿ Qué pasa si partes de la URL, URL codificadas? Las soluciones aquí nuevamente, la incorporación de un número de secuencia creciente a cada URL de entrada para que sea único y generar su hash. Y otra solución podría ser anexar el ID de usuario, que debería ser único a la URL de entrada. Si el usuario no ha iniciado sesión aquí, podría ser un problema porque necesitaríamos eso para confirmar la singularidad de la clave. Incluso si después de todos estos pasos que dimos para estar seguros de que nada crezca podría pasar, todavía tenemos un conflicto. Podemos seguir generando la clave hasta que consigamos la única. Envolviendo el diseño básico del sistema una parte de algoritmo. La segunda parte aquí sería la partición de datos y replicación de nuestro servicio. Para escalar nuestra base de datos, necesitamos particionarla para que pueda almacenar más información. Necesitamos alrededor de miles de millones de entradas en nuestra base de datos. Y aquí podemos echar un vistazo a los dos tipos de particionamiento que hay, que son la llave basada y la partición basada en hash. Comenzando con el rango basado particionamiento fines de semana URL del portal en particiones separadas basadas en las claves hash, caracteres, o incluso uno de ellos. Entonces podemos guardar todas las URLs empezando por ejemplo, trigo o letra a en una partición, y guardando las que empiezan con la letra B en otra, y así sucesivamente. Y mirando en contraste el particionamiento basado en hash-basado en este esquema, podemos tomar el hash del objeto que estamos almacenando y luego calcular en base a aquella que partición usar. En nuestro caso, podemos tomar el hash de la clave o el acortamiento para determinar la partición que vamos a iniciar esa URL específica. Lo siguiente que debemos pensar al acercarnos al problema de diseño del sistema es la parte de efectivo. Por lo que podemos coger URLs a las que se accede con frecuencia como ya sugerimos anteriormente. Y podemos usar cualquiera de la solución de estantería que existe por ahí por memcached por ejemplo. Pero también podemos almacenar URLs completas. Y al hacer eso almacenar la URL completa dulces sus respectivos hashes en su dedicación surfista. En este enfoque, antes de que puedas pensar, el almacenamiento back-end puede comprobar rápidamente si la caché ya tiene la URL de diseño. Y de esta manera un servicio más óptimo. También tenemos que pensar aquí en cuánta memoria caché deberíamos tener. Para que podamos empezar. Alrededor del 20% del tráfico diario y en base a los patrones de uso del cliente, ajustar además, cuántos casos servidores necesitamos. Según lo estimado anteriormente, necesitamos unos 170 gigabytes de memoria para cobrar el 20% del tráfico. Dado que un servicio moderno puede tener 256 gigabytes de memoria, puede caber fácilmente todo el efectivo en una sola máquina. Esto fue por ello con la parte de almacenamiento en caché. También podemos pensar en el equilibrador de carga en nuestro sistema, que es bastante sencillo. Podemos pensar en agregar estas capas de equilibrio de carga en tres lugares. Y esos serían entre clientes y los servidores de aplicaciones, y también entre servidores de aplicaciones y servidores de bases de datos y servidores de caché. Pasando a la cosa de la danza en la que tenemos que pensar cuando se dan estos sistemas diseño entrevista pregunta nosdan estos sistemas diseño entrevista preguntaes la purga o la limpieza de la base de datos. El ingreso, por supuesto, no debe quedarse para siempre en nuestra base de datos ya que la llenaría y se desbordaría causando un accidente. Época. ¿ Se alcanza un tiempo de caducidad especificado? ¿ Qué debe pasar con el enlace? Bueno, si decidimos buscar continuamente experimentos para eliminarlos, también pondría mucha presión en nuestra base de datos. Entonces en cambio podemos eliminar lentamente los enlaces vencidos haciendo una limpieza perezosa. Y la forma en que nuestro servicio se asegurará que solo los enlaces caducados serán eliminados con B por cada vez que el usuario intente acceder al enlace inspirado, eliminamos haciéndolos el código de entrada al usuario. De esta manera no eliminar todas las URL expiraron a la vez y arriesgando un bloqueo de la base de datos. También podemos tener un tiempo de caducidad predeterminado para cada enlace en lo que va este aspecto. Por último, también hay que tener en cuenta que el árbol de límites, que debe responder a algunas preguntas ya que cuántas veces es URL corta se ha utilizado. ¿ Cuál fue la ubicación del usuario? ¿ Cuál sería la fecha y hora de acceso y así sucesivamente. Parte de seguridad y permisos, que es otra importante. Podemos almacenar el nivel de permisos con cada URL en la base de datos siendo pública o privada. Para los privados, también podemos crear una tabla separada para almacenar los ID de usuario que tengan permisos para ver esa URL específica. Por supuesto, si no tiene ese permiso, nuestro punto final o x está en la URL corta, puede devolver un HTTP para un código uno, significa que no hay suficiente eje. Por supuesto. Esto fue sobre todo los ángulos que hay que tener en cuenta al acercarse a una solución a la pregunta de superficie URL de acortamiento en una revisión del diseño del sistema. Espero que ustedes realmente hayan sacado algo de esta conferencia. Y muchas gracias por quedarse conmigo hasta el final de la misma. También espero veros chicos en la siguiente. 5. La aplicación de compartir fotos: Hola chicos y bienvenidos de nuevo al tutorial de entrevista de diseño del sistema donde entendemos cómo podemos pasar una entrevista que se compone de preguntas de C3b firmar. En esta conferencia, vamos a discutir otro problema muy común que se da este tipo de entrevistas y echar un vistazo a exactamente cómo podemos resolverlas para pasar, como ya he dicho, la entrevista. El problema que no vamos a ver en esta conferencia es diseñar un servicio de intercambio de fotos. Aquí los usuarios pueden subir fotos para compartirlas con otros usuarios. Y por supuesto, algunos servicios similares pueden ser Flickr o algunas plataformas de redes sociales, aunque tengan más funcionalidades integradas dentro de ellas. En primer lugar, a la hora de abordar este problema, voy a utilizar la plantilla general que se ajusta para cualquier pregunta de diseño de sistema que se pueda dar en una entrevista de la que hablé en una conferencia previa. Y el primer paso después de entender a fondo la pregunta y hacer cualquier otra aplicación de consulta que pueda tener de su entrevistador es definir los requisitos y los objetivos de el sistema del que vas a hablar. Al diseñar nuestra aplicación para compartir fotos, nos gustaría tener algunos requisitos funcionales que incluyen que un usuario pueda seguir algunos otros usuarios que tienen una cuenta en esta plataforma. El usuario también puede realizar algunas búsquedas que pueden basarse en las fotos que se comparten. ¿ Ha buscado también puede subir fotos ellos mismos desde su cuenta. Y el sistema que vamos a implementar también debe generar y mostrar algún tipo de feed de noticias donde un usuario, cuando abra la aplicación, verá las mejores fotos de la gente que luchó arcos. Estos son, como dije, los requisitos funcionales, pero también hay que pensar en los funcionales. El requisito no funcional número uno tiene que ser que el sistema sea muy confiable, lo que significa que una vez que el usuario sube una foto en nuestra superficie, la foto no se perderá. A continuación, nuestra superficie necesita estar altamente disponible, por lo que cualquier duda no está permitida. Además, debemos mantener nuestra latencia baja para la regeneración de noticias y cosas así. Significa la cantidad de tiempo que el usuario realmente esperará desde el inicio de la aplicación hasta el punto en que realmente verá algunas fotos de otros usuarios que sigue. Por lo que ahora se hace el primer paso. Y definimos los requisitos y los objetivos del sistema que estamos a punto de diseñar. Podemos hacer algunas otras consideraciones de diseño. Aquí. Podemos empezar por el hecho de que todos estos servicios que vamos a implementar, es bastante obvio que será muy leído pesado porque la deuda neta cuando los usuarios realmente subirán fotos, pero un número mucho mayor de usuarios en realidad verá las fotos que vi otros usuarios. Puedes pensar esto, como pensarías al publicar una fotografía en tu aplicación de redes sociales. Publica muy pocas veces, pero en realidad ves muchas otras características en comparación para ver que realmente subes. Entonces por eso este sistema se leerá pesado. el hecho de que nuestro servicio se leerá pesado, necesitamos enfocarnos en recuperar. La foto es muy rápida. Ahora, los usuarios pueden subir tantas fotos como la luz del día también. Entonces eso es algo a tener en cuenta porque necesitamos una gestión muy eficiente del almacenamiento para estas fotos. Y además, guardo dicho, si un usuario sube una foto, este sistema que diseñamos, garantizamos que no se perderá. Pasando ido a alguna estimación y limitaciones para la capacidad de las cosas que vamos a almacenar. Podemos suponer que vamos a tener 100 millones de usuarios con cerca de 10 mil usuarios activos diarios y 2 millones de fotos nuevas cada día. Eso serían alrededor de 23 fotos nuevas cada segundo. Y estos cálculos que vamos a hacer aquí con se llevan a cabo en una fecha más donde nuestro servicio será altamente adoptado y exitoso. Entonces por eso me ves romper estas cantidades muy altas para estas. Un números reales. Ahora, el espacio total requerido para un día de fotos, como dije, sería de unos 2 millones porque dijimos que tendríamos 2 millones de fotos nuevas cada día. Y podemos pensar en el tamaño promedio del archivo fotográfico, que puede ser de 100 kilobytes, que va a ser unos 200 gigabytes en total para nuestra capacidad. Ahora eso es sólo tomar en cuenta un día. Pero, ¿y si señalamos el espacio, digamos, cinco años? Bueno, podemos multiplicar 200 por 3655 años, y vamos a conseguir unos 365, por lo que 365 terabytes. Ahora que tenemos esta estimación de capacidad fuera del camino, podemos pensar en el diseño del sistema de alto nivel. Porque a un nivel alto solo necesitamos apoyar dos escenarios. Uno para subir las fotos, que es flujo de trabajo en nuestro servicio. Y sí, querían ver o buscar estas fotos. El servicio que vamos a implementar, por supuesto, necesita almacenar las fotos en alguna base de datos. Y vamos a necesitar algunos servidores de almacenamiento de objetos aquí. Además, al esquema de base de datos para almacenar estas fotos, también va a ser discutido en la entrevista. Tenemos que tener en cuenta que sí tenemos cerca de tres entidades. Uno que va a ser el usuario, a continuación, las fotos, y luego los usuarios que sigan. El esquema puede contener tres tablas. Cuando una foto, que puede tener una identificación con foto, que va a ser la clave principal. Y luego algunos otros campos como el ID de usuario, que es por supuesto que el usuario muerto lo publicó, que va a ser una clave foránea en esta tabla. Entonces un otro campo muy importante aquí va a ser fecha de creación, que va a ser de tipo datetime. Y este es un campo muy importante porque va a ser útil cuando el usuario abra su feed de noticias, queríamos conseguirle las fotos más recientes y más populares, pero para la última parte vamos a comer esa región golpeó campo. Entonces también tenemos la tabla de usuarios, que por supuesto tendrá una clave principal de User ID. Y luego algunos otros datos que queríamos almacenar para él. Si queremos hacer marketing por correo electrónico puede conservar su correo electrónico. Pero también necesitamos el nombre, la fecha de nacimiento, la fecha de cada cuenta, y tal vez el último inicio de sesión. Estoy pensando. También necesitaríamos una tabla para el seguimiento del usuario, que tomaría campo que ambos formarán parte de la clave primaria. Y eso será, por supuesto, identificadores de usuario de los usuarios que se siguen unos a otros. lo que esto por supuesto toma en cuenta en el escenario donde el usuario de seguimiento cada uno va en ambos sentidos, como en Facebook cuando se agrega un amigo. Entonces si te aceptaras a los dos como amigo, no como un Instagram donde el seguimiento puede ser unidireccional. Para que puedas seguir a alguien que no te seguiría. No tenemos ese escenario en esta discusión sólo para que podamos hacerlo un poco más sencillo. Ahora el enfoque sencillo para asaltar los detectores de esquema hablan sería un MySQL requerir obviamente las articulaciones, pero podemos almacenarlo en una tienda de valor clave distribuida para disfrutar de la beneficios que ofrece NoSQL también. Después de hablar del esquema de base de datos en nuestra entrevista, también necesitamos tomar otra estimación del tamaño de los datos. Por lo que la D decide estimación sobre el contiene información sobre los campos que se van a almacenar en nuestra base de datos. Y tenemos que pensar en los enteros, cadenas y así sucesivamente. Posteriormente se va a almacenar en nuestra base de datos. Podemos suponer que cada consulta de entrada y la DateTime más allá de cuatro bytes. Por lo que cada fila en la tabla de usuarios será de unos 68 bytes. Si hubiera, como conté antes, alrededor de seis campos. Si tendríamos, digamos, 250 millones de usuarios, vamos a necesitar alrededor de 16 gigabytes de almacenamiento solo para la parte del usuario se pueda almacenar con toda su información en nuestra base de datos. Pero ¿qué pasa con las fotos? Por lo que cada fila en la tabla fotográfica será unos 284 bytes Cs. También tenemos pack de fotos, que va a ser var gráfico hasta 265 caracteres y que lleva 265, mira la entrada fotográfica que sería bastante más larga que la del usuario, pero eso sería bastante normal. Si tomamos en cuenta alrededor de 1 millón de fotos nuevas que se suben todos los días, vamos a necesitar unos 200 y A 50 megabytes de almacenamiento por un día. Y eso va a ser en diez años, alrededor de un terabyte, casi. El último cuadro, cada el usuario sigue tabla. Y si se compone de ocho bytes, sólo teníamos la clave primaria compuesta por dos integrales, que son cada uno cuatro bytes. Podemos pensar en 250 millones de usuarios. Pueden seguir otros 250 millones de usuarios y vamos a cumplir con otro adicional petabytes de almacenamiento para el usuario seguido tabla. El espacio total requerido para todas estas mesas para los oídos, como dije, sería de unos dos terabytes, lo que en realidad es bastante grande para una aplicación. Y la superficie de este tipo. El próximo fin de semana también echó un vistazo rápido al diseño de los componentes que vamos a tener en este servicio. La foto sube o derecha skimpy lento. Lee quiénes van a ser más rápidos, sobre todo si están siendo atendidos desde efectivo. Subir, los usuarios pueden consumir conexiones de deck que están disponibles porque la carga es un proceso lento y eso significa que no se nos puede servir. Cualquiera de los dos sistemas se pone ocupado con todas las solicitudes correctas. Debemos tener en cuenta que estos servicios web tienen una conexión si nos reunimos antes de diseñar el sistema. Entonces si asumes que un servidor web puede tener un máximo de 500 conexiones a n tiempo, entonces puede tener más de 500 subidas concurrentes o lecturas manejadas estos cuello de botella, podemos dividir lecturas y escribe en servicios separados. Esto también nos permitirá en el futuro escalar estas operaciones de forma independiente y mucho más fácil ya que son dos entidades separadas. Para la parte de redundancia ahora, perder archivos es que he mencionado anteriormente, no es una opción. Podemos iniciar múltiples copias de cada archivo como solución a la deuda. Porque si uno de almacenamiento dados, podemos recuperar el cuarto demasiado fuerte, la otra copia. Pero el mismo principio también se aplica a otros componentes. Entonces si queremos tener la disponibilidad del sistema que sería alto vender nuestro sistema no estaría muriendo en ningún momento en el tiempo. También necesitamos tener réplicas del servicio funcionando. Los servicios murieron. El sistema permanece disponible en aterrador ya que esta redundancia elimina el único punto de falla en el sistema. Ese es un punto muy importante. Al tomar cualquier entrevista de diseño de sistema, hay que pensar si está implementando en realidad está haciendo un solo punto de falla La deuda S es una desventaja y hay que observar. Y también necesitas encontrar una solución para ello. Si sólo una instancia de los servicios requeridos para ejecutarlo en cualquier punto, podemos ejecutar una copia secundaria redundante del servicio que no está atendiendo ningún tráfico, pero puede tomar el control después de la fatal para sordos blancos primarios tiene problema. Como ya he dicho, son dos instancias del mismo servicio que se ejecutan en producción y una falla. El sistema puede fallar a la copia sana. Y esto puede suceder de forma automática o requerir intervención manual, aunque si no entras en tu sistema hacia abajo en ningún momento en el tiempo, mejor implementarías y recuperaras automáticamente. Porque de lo contrario, tendría que hacer observar que su sistema es goma de mascar y luego intervenir manualmente con la deuda del desarrollador puede por supuesto por sí mismo redirigir la 17ª 2D disponible. También podemos hablar del sharding de datos. Porque por supuesto creo que cantidades tan altas de datos, necesitamos de alguna manera compartirlos. Podemos trazar en el ID de usuario para que podamos mantener todas las fotos de un usuario en el mismo DB agudo y definido corto es uno terabytes. Necesitarías cuatro gráficos para almacenar unos cuatro terabytes de datos. Ahora, para el rendimiento y escalabilidad fin de semana mantén cerca de diez de ellos. Nuevamente, el sistema FOR crece cada vez más grande, vamos a ser capaces de manejar todo el tráfico de deudas. Vamos a necesitar encontrar el número agudo por usuario múltiplo de diez. Empecemos ahí. Identificar de forma única cualquier foto en nuestro sistema. Podemos anexar este número a la identificación con foto, y esa sería una solución bastante simple al respecto. ¿ Cómo podemos generar los identificadores fotográficos mientras que cada base de datos puede tener su propia secuencia de incremento automático para los identificadores fotográficos. Y como vamos a anexar esta idea de la identificación con foto aguda, hará única en todo nuestro sistema. A pesar de que se nos ocurrió este sistema de particionamiento, tiene algunas inconvenientes. Por ejemplo, si no podemos almacenar todas las imágenes en exceso usando mi gráfico, tenemos que distribuir eso a múltiples ellas y causará mayor enfermedad posterior. Y también los usuarios del corazón necesitan ser manejados de manera bastante diferente porque son seguidos por muchos otros usuarios y mucha gente. Verán su subida las fotos y la deuda puede conseguir causar problemas en ese sentido. Podemos por supuesto, particionar alrededor de la identificación con foto y no el ID de usuario, que puede ser otro enfoque. Porque si generalmente estos ID con foto es primero, podemos encontrar el número agudo a través de nuevo, el módulo de identificación con foto, lo que significa que son menos dígitos básicamente. Y por supuesto, los problemas anteriores de los que acabamos de hablar que fueron los inconvenientes después del primer acercamiento habrían sido resueltos en este punto. Nuevamente, para generar los identificadores fotográficos, no puedes tener una secuencia de auto-incremento porque necesitas saber foto ID es primero definir la solución nítida aquí podría ser dedicar una base de datos separada instancia para generar estos ID de auto-incremento, necesitamos también pensar mucho en el futuro y combinar nuestro crecimiento del sistema. Si tenemos gran cantidad de particiones lógicas para acumular el crecimiento de los datos al principio, múltiples particiones lógicas dentro en una sola base de datos física, base datos CCS, o podemos tener múltiples sistemas de bases de datos que se ejecutan en él. Podemos tener bases de datos separadas para cada partición lógica en cualquier servidor. Siempre que sentimos que un servidor de base de datos en particular tiene muchos datos, podemos crear algunas particiones lógicas a otro servidor, y podemos mantener un archivo de config. Y eso constituiría lo único que tendríamos que actualizar para anunciar un eventual cambio. El ranking y la generación de noticias es otro problema al que nos enfrentamos. La forma en que vamos a lidiar con ello. O al menos una forma en la que podemos lidiar con ello es pregenerar el feed estadounidense. Podemos tener algunos servidores que su única tarea sería generar usuarios para continuamente y almacenarlos en otra tabla llamada feed de noticias de usuario. Cuando el usuario necesite barriga esta foto para nueva suite, simplemente consultaremos esta tabla y devolveremos los resultados. Leslie, también necesitamos pensar el balanceo de efectivo y carga del sistema ya que será muy usado uno, necesitamos introducir un caché para mí a Data Service para coger las filas de la base de datos. Eso significa las carpetas calientes y los usuarios. Podemos usar caso de demanda para caso de estos datos y servidores de aplicaciones Ahí habrá antes de golpear la base de datos puede comprobar rápidamente si el caché tiene las rutas deseadas. Aquí, un enfoque que sería razonable sería la R U, que es la menos utilizada recientemente. Por la política de desalojo de caché. Podemos construir el integrador más inteligente Kiersten, estos usando la regla 8020, que establece que el 280% del volumen de fotos que se van a leer diariamente, generaremos el 80% del tráfico, por lo que sólo podemos cobrar ese primer 20%. Entonces esto fue sobre todos los pasos y datos interminables. Consideraría un impotente en la entrevista de diseño de sistemas y recibiría una implementación de diseño de servicio de intercambio de fotos. Les agradezco muchísimo chicos por quedarse conmigo hasta el final de esta conferencia. Y espero verte en la siguiente.