Existe una pregunta que aparece en casi todas las rondas de entrevistas de diseño de sistemas en las principales empresas tecnológicas. El entrevistador se inclina hacia adelante, abre una pizarra en blanco o un documento compartido y dice: “Diseña Twitter.”
Dos candidatos escuchan la misma pregunta.
Uno habla durante 40 minutos y aún así es rechazado. El otro habla durante el mismo tiempo y recibe una sólida recomendación de contratación.
La diferencia no radica en conocer más tecnologías. Se trata de cómo estructuras tu pensamiento, cómo descompones el problema y cómo comunicas las compensaciones de manera clara.
Precisamente por eso es tan importante una comparación lado a lado de una respuesta débil frente a una respuesta sólida para diseñar Twitter. Cuando ves cómo se ve una respuesta débil junto a una sólida, las diferencias se hacen evidentes.
Y una vez que ves esas diferencias, puedes corregirlas antes de tu próxima entrevista.
Comprender cómo abordar esta pregunta correctamente es fundamental porque Twitter (ahora X) representa una clase de problemas. Combina feeds en tiempo real, un tráfico masivo con predominio de lecturas, relaciones de usuarios y distribución de contenido.
Si puedes diseñar Twitter bien, puedes manejar docenas de preguntas similares sobre feeds sociales, sistemas de notificaciones y plataformas de contenido.
Antes de analizar la respuesta débil frente a la sólida, aclaremos qué significa “Diseña Twitter” en el contexto de una entrevista.
El entrevistador no te está pidiendo que construyas toda la plataforma. Quiere ver cómo piensas al diseñar un sistema a gran escala.
Específicamente, está probando si puedes hacer cuatro cosas.
Primero, ¿puedes recopilar y aclarar los requisitos en lugar de lanzarte directamente a una solución?
Segundo, ¿puedes proponer una arquitectura de alto nivel que tenga sentido?
Tercero, ¿puedes profundizar en componentes específicos y explicar cómo funcionan entre bastidores?
Y cuarto, ¿puedes discutir las compensaciones y los desafíos de escalabilidad con madurez?
Una respuesta débil omite la mayoría de estos pasos.
Una respuesta sólida cubre los cuatro en una forma estructurada y segura.
Esa es la diferencia fundamental que vamos a exponer en este análisis de diseño de Twitter.
Lo primero que separa una respuesta débil de una sólida es lo que sucede en los primeros dos minutos.
Aquí es donde la comparación lado a lado de la respuesta débil y sólida para diseñar Twitter se vuelve interesante.
Respuesta Débil:
“OK, Twitter tiene tweets, usuarios y una línea de tiempo. Déjame empezar a dibujar la arquitectura…”
Respuesta Sólida:
“Antes de empezar, me gustaría aclarar el alcance. ¿Nos estamos enfocando en las funciones básicas de tweets y líneas de tiempo, o también en la búsqueda, las tendencias, los mensajes directos y las notificaciones? ¿Qué escala estamos apuntando? ¿Cuántos usuarios activos diarios?”
La respuesta débil se lanza directamente a la construcción. El candidato asume que ya sabe lo que necesita ser diseñado.
Este es uno de los errores más comunes en las entrevistas de diseño de sistemas.
La respuesta sólida comienza con preguntas.
Al preguntar sobre el alcance, el candidato demuestra al entrevistador que comprende que los sistemas reales tienen límites. También se da claridad. Tal vez el entrevistador solo quiera que se concentre en la publicación de tweets y el feed de noticias.
Eso cambia todo sobre la profundidad con la que profundizas en cada componente.
Aquí hay un ejemplo de requisitos sólidos para Diseñar Twitter:
-
Los usuarios pueden publicar tweets (280 caracteres, con imágenes o videos opcionales)
-
Los usuarios pueden seguir a otros usuarios
-
Los usuarios ven una línea de tiempo con tweets de las personas que siguen
-
El sistema maneja 500 millones de usuarios activos diarios con 200 millones de tweets diarios
-
Carga de trabajo con predominio de lecturas: las lecturas de la línea de tiempo superan con creces las escrituras de tweets
Observa cómo la respuesta sólida define tanto los requisitos funcionales (lo que hace el sistema) como los requisitos no funcionales (escala, rendimiento, disponibilidad).
Un “requisito funcional” es una función que el sistema debe admitir. Un “requisito no funcional” describe qué tan bien debe funcionar, como la velocidad o el tiempo de actividad.
Aquí es donde la brecha entre la respuesta débil y la sólida para diseñar Twitter se amplía más.
La fase de diseño de alto nivel revela si un candidato comprende los sistemas distribuidos o simplemente está enumerando las tecnologías que ha escuchado.
Respuesta Débil:
“Tendremos un servidor, una base de datos y una caché. El servidor lo maneja todo. Podemos usar MySQL para la base de datos.”
