Diseñar un sistema que soporte millones de lecturas simultáneas no es trivial, y precisamente ese es el desafío que se plantea en esta etapa del curso. La tarea consiste en crear un documento de diseño a bajo nivel (low-level design) para el servicio de lectura, tomando como punto de partida el servicio de escritura ya implementado y una base de datos NoSQL existente.
¿Qué debe incluir el documento de diseño a bajo nivel?
El documento de diseño a bajo nivel es aquel que detalla con la mayor precisión posible cómo se va a implementar un componente del sistema. No se trata de diagramas generales, sino de decisiones concretas sobre tecnologías, modelos de datos y flujos de comunicación. Para este reto, el documento debe cubrir tres pilares fundamentales [01:52]:
- Diseño de entidades: la entidad principal es el review, es decir, la reseña ya procesada y lista para ser consumida por el cliente.
- Arquitectura de servicios: cómo se conectan los componentes entre sí y con la base de datos NoSQL ya existente (en el ejemplo se usa Azure Cosmos DB, pero puedes elegir cualquier proveedor).
- Modelado de datos: incluir un ejemplo en JSON del payload que retornará el API cuando reciba una petición GET.
Este último punto es crucial. Definir la carga de datos que el cliente va a recibir permite que cualquier equipo que consuma el API sepa exactamente qué esperar [05:30].
¿Por qué el servicio debe ser stateless y escalar horizontalmente?
Uno de los requisitos más importantes del reto es que el servicio de lectura pueda atender millones de usuarios leyendo de forma concurrente [03:35]. Para lograrlo, se recomienda que el servicio sea stateless, es decir, que no mantenga estado interno.
¿Qué significa stateless en la práctica?
Un servicio stateless no guarda información en las máquinas virtuales donde se ejecuta [04:05]. Ninguna operación de storage o escritura en base de datos ocurre dentro de esas VMs. Esto tiene una ventaja directa: puedes añadir más instancias sin preocuparte por sincronizar datos entre ellas.
¿Cómo funciona la escalabilidad horizontal?
La escalabilidad horizontal consiste en agregar más máquinas virtuales para distribuir la carga, en lugar de hacer más potente una sola máquina [04:15]. Si el servicio es stateless, cada nueva VM puede empezar a recibir peticiones de inmediato, lo que permite crecer de forma prácticamente ilimitada según la demanda.
¿Qué libertades y recomendaciones hay para la solución?
El reto ofrece total flexibilidad tecnológica. Puedes usar el proveedor cloud que prefieras (Azure, AWS, GCP) o incluso trabajar de manera local [01:30]. También puedes elegir bases de datos adicionales como MySQL, incorporar capas de caché para optimizar las lecturas, o decidir entre servicios serverless y serverful según tu criterio [02:40].
Sin embargo, al tratarse de un diseño a bajo nivel, ya es necesario especificar las tecnologías concretas [06:05]:
- Proveedor cloud seleccionado.
- Base de datos (relacional o no relacional).
- Lenguaje de programación (opcional, ya que la mayoría pueden resolver este tipo de problema).
- Componentes intermedios como caché o colas si los consideras necesarios.
La fuente de información principal será la base de datos NoSQL que ya alimenta el servicio de escritura [03:10]. Tu servicio de lectura debe conectarse a ella, transformar los datos y regresarlos como respuesta a una petición GET.
¿Cómo obtener retroalimentación efectiva?
Una vez terminado el documento, la siguiente tarea es buscar feedback de colegas o compañeros [00:40]. Iterar sobre el diseño a partir de la retroalimentación es lo que más se acerca a la dinámica real de la industria. No se trata de entregar un documento perfecto a la primera, sino de mejorarlo a través de revisiones sucesivas.
La recomendación final es clara: apóyate en los recursos disponibles, pero prioriza tu propio análisis y creatividad. Construir una solución desde cero, con tus propias decisiones arquitectónicas, es lo que realmente consolida el aprendizaje. ¿Ya tienes en mente qué tecnologías vas a elegir para tu servicio de lectura?
