Esta lección se tradujo automáticamente al español y aún no ha sido revisada por una persona. Si algo suena raro, la versión en inglés es la definitiva.
Cada aplicación a gran escala se ensambla a partir de los mismos componentes fundamentales. Los entrevistadores no esperan que usted invente nueva tecnología: quieren verlo seleccionar y combinar los componentes correctos para un problema determinado. Esta lección cubre el conjunto de herramientas que utilizará en cada entrevista de diseño.
En esencia, la web sigue un modelo simple: los clientes envían solicitudes, los servidores las procesan y las respuestas fluyen de regreso. Pero los sistemas modernos agregan capas entre estos dos puntos finales para manejar la escala, la confiabilidad y el rendimiento.
Una solicitud típica podría atravesar: cliente → CDN → balanceador de carga → puerta de enlace API → servidor de aplicaciones → caché → base de datos. Cada capa resuelve un problema específico, y comprender cuándo cada capa es necesaria separa a los candidatos fuertes de los promedio.
En las entrevistas, comience siempre esbozando el flujo cliente-servidor de alto nivel antes de profundizar en los detalles. Muestra pensamiento estructurado.
Un único servidor tiene una capacidad finita. Los equilibradores de carga distribuyen las solicitudes entrantes entre varios servidores mediante estrategias como:
Los balanceadores de carga también realizan verificaciones de estado, eliminando automáticamente los servidores en mal estado del grupo. En entornos de nube, servicios como AWS ALB o Azure Front Door manejan esto de forma transparente.
Un servicio de alimentación de redes sociales recibe 10 veces más lecturas que escrituras. ¿Qué enfoque de equilibrio de carga garantiza mejor que los usuarios accedan constantemente al mismo servidor con caché?
Inicia sesión para unirte al debate
El almacenamiento en caché almacena los datos a los que se accede con frecuencia más cerca del consumidor. Existe en múltiples niveles:
| Capa | Ejemplo | Latencia | |-------|---------|---------| | Caché del navegador | Activos estáticos, respuestas API | ~0ms | | CDN | Imágenes, archivos CSS, JS | ~10-50ms | | Caché de aplicaciones | Redis, Memcached | ~1-5ms | | Caché de base de datos | Caché de resultados de consulta | ~5-10ms |
La invalidación de la caché es famosa por ser uno de los problemas más difíciles en informática. Las estrategias comunes incluyen TTL (tiempo de vida), escritura directa (actualizar el caché en cada escritura) y caché aparte (la aplicación administra el caché explícitamente).
La famosa cita de Phil Karlton - "Sólo hay dos cosas difíciles en Ciencias de la Computación: invalidación de caché y nombrar cosas" - es tan citada que es prácticamente un rito de iniciación en las entrevistas de diseño de sistemas.
Elegir la base de datos adecuada es una de las decisiones de diseño más impactantes:
Las bases de datos SQL (PostgreSQL, MySQL) ofrecen transacciones ACID, gran coherencia y esquemas estructurados. Sobresalen cuando los datos tienen relaciones claras y se necesitan consultas complejas con combinaciones.
Las bases de datos NoSQL vienen en varios tipos:
Está diseñando un sistema que almacena perfiles de usuario con datos semiestructurados que cambian con frecuencia (diferentes campos por tipo de usuario). ¿Qué tipo de base de datos es el más adecuado?
No todas las operaciones necesitan una respuesta inmediata. Las colas de mensajes (RabbitMQ, Apache Kafka, AWS SQS) desacoplan a los productores de los consumidores, lo que permite:
Kafka merece una mención especial: no es solo una cola sino un registro de eventos distribuido, que permite arquitecturas basadas en eventos donde varios consumidores pueden procesar de forma independiente el mismo flujo de eventos.
| Aspecto | Monolito | Microservicios | |--------|----------|---------------| | Implementación | Unidad única | Servicios independientes | | Escalado | Escalar todo junto | Escalar servicios individuales | | Complejidad | Más sencillo de empezar | Gastos operativos | | Datos | Base de datos compartida | Base de datos por servicio |
Inicie monolito, extraiga microservicios cuando sea necesario. La mayoría de los entrevistadores aprecian a los candidatos que reconocen que los microservicios introducen complejidad en el sistema distribuido (fallas de red, coherencia de datos, orquestación de implementación) y no siempre son la opción correcta.
Netflix migró de un monolito a microservicios a lo largo de varios años. Pero Shopify, que maneja miles de millones en transacciones, todavía ejecuta un monolito modular. ¿Qué factores podrían hacer que un enfoque sea mejor que el otro para una empresa determinada?
El teorema CAP establece que un sistema distribuido puede garantizar sólo dos de tres propiedades simultáneamente:
Dado que las particiones de red son inevitables en los sistemas distribuidos, la verdadera elección es entre CP (coherencia sobre disponibilidad) y AP (disponibilidad sobre coherencia).
Estás diseñando un sistema de transacciones bancarias donde los saldos incorrectos podrían causar pérdidas financieras. ¿Qué compensación de la PAC debería priorizar?
Cuando ingrese a una entrevista de diseño de sistema, siga esta estructura:
Piense en un sistema que utiliza a diario: Instagram, Uber o Spotify. ¿Puedes identificar qué componentes básicos de esta lección probablemente utilice? ¿Dónde se ubicaría el balanceador de carga? ¿Qué se almacenaría en caché? ¿Qué tipo de base de datos se ajusta a su modelo de datos?
A continuación: aplicaremos estos fundamentos para diseñar un acortador de URL desde cero.