Quiz de Arquitectura
Pon a prueba tu conocimiento con preguntas de opción múltiple sobre patrones, decisiones y conceptos de arquitectura de software.
Objetivo
Este quiz cubre los conceptos fundamentales de arquitectura de software que se tratan en las secciones anteriores. Úsalo para evaluar tu comprensión y detectar áreas donde necesitas profundizar.
Cada pregunta tiene una explicación detallada — no te quedes solo con la respuesta correcta, lee el porqué.
Sección 1: Fundamentos
Pregunta 1
¿Cuál es la principal diferencia entre un monolito y microservicios?
- A) Los microservicios usan más tecnologías
- B) Los microservicios se despliegan de forma independiente
- C) Los monolitos no pueden escalar
- D) Los microservicios son siempre más rápidos
Ver respuesta
Respuesta: B
La diferencia fundamental es el despliegue independiente. Cada microservicio puede desplegarse, escalarse y actualizarse sin afectar a los demás. Un monolito se despliega como una unidad.
Los monolitos sí pueden escalar (verticalmente o con múltiples instancias). Los microservicios no son inherentemente más rápidos — de hecho, la comunicación por red agrega latencia.
Pregunta 2
¿Qué principio arquitectónico sugiere que los módulos de alto nivel no deben depender de módulos de bajo nivel?
- A) Single Responsibility Principle
- B) Open/Closed Principle
- C) Dependency Inversion Principle
- D) Interface Segregation Principle
Ver respuesta
Respuesta: C
El Dependency Inversion Principle (DIP) establece que:
- Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
- Las abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones.
En la práctica, esto significa usar interfaces o contratos entre capas, no dependencias directas a implementaciones concretas.
Pregunta 3
¿Cuándo es apropiado elegir un monolito sobre microservicios?
- A) Nunca — los microservicios son siempre superiores
- B) Cuando el equipo es pequeño y el dominio no está bien definido
- C) Solo para prototipos que se van a tirar
- D) Cuando no tienes presupuesto para cloud
Ver respuesta
Respuesta: B
Un monolito (especialmente un monolito modular) es una excelente elección cuando:
- El equipo es pequeño (< 8 personas)
- El dominio no está bien definido (los límites de servicios cambiarán)
- La velocidad de desarrollo es más importante que la escalabilidad independiente
- No tienes la infraestructura para operar sistemas distribuidos
Los microservicios agregan complejidad operativa significativa. Si no la necesitas, no la agregues.
Sección 2: Patrones
Pregunta 4
¿Qué patrón usarías para evitar que un servicio externo lento colapse tu sistema?
- A) Saga Pattern
- B) Circuit Breaker
- C) Outbox Pattern
- D) CQRS
Ver respuesta
Respuesta: B
El Circuit Breaker detecta cuando un servicio externo está fallando o respondiendo lento, y “abre el circuito” para dejar de enviarle requests. Esto evita que los threads se bloqueen esperando respuestas que no llegan, protegiendo tu sistema de una cascada de fallos.
Estados del circuit breaker:
- Cerrado: todo funciona normal, los requests pasan
- Abierto: el servicio está fallando, los requests se rechazan inmediatamente
- Semi-abierto: se permite un request de prueba para ver si el servicio se recuperó
Pregunta 5
¿Cuál es el propósito principal del patrón Outbox?
- A) Enviar emails de forma asíncrona
- B) Garantizar consistencia entre la base de datos y el message broker
- C) Almacenar mensajes que fallaron para reintentarlos
- D) Separar las lecturas de las escrituras
Ver respuesta
Respuesta: B
El Outbox Pattern resuelve el problema de la escritura dual: cuando necesitas actualizar la base de datos Y publicar un evento, y ambas operaciones deben ser atómicas.
En vez de publicar directamente al broker, escribes el evento en una tabla “outbox” dentro de la misma transacción de base de datos. Un proceso separado lee la tabla outbox y publica los eventos al broker. Si el publish falla, se reintenta. Si la transacción falla, el evento nunca se escribió en la outbox.
Pregunta 6
¿Qué patrón permite que un servicio maneje requests de lectura y escritura de forma diferente?
- A) Saga
- B) Event Sourcing
- C) CQRS
- D) API Gateway
Ver respuesta
Respuesta: C
CQRS (Command Query Responsibility Segregation) separa el modelo de lectura del modelo de escritura. Esto permite:
- Optimizar las lecturas con modelos desnormalizados
- Escalar lecturas y escrituras de forma independiente
- Usar diferentes bases de datos para cada modelo
CQRS no requiere Event Sourcing, aunque frecuentemente se usan juntos.
Sección 3: Resiliencia y operaciones
Pregunta 7
¿Qué estrategia de retry es más apropiada para llamadas a servicios externos?
- A) Retry inmediato sin límite
- B) Retry con backoff exponencial y jitter
- C) Retry cada 1 segundo, máximo 100 veces
- D) No hacer retry — si falla, falla
Ver respuesta
Respuesta: B
El backoff exponencial con jitter es la estrategia recomendada porque:
- Backoff exponencial: cada reintento espera más tiempo (1s, 2s, 4s, 8s…), dando tiempo al servicio para recuperarse
- Jitter: agrega un componente aleatorio al delay para evitar que todos los clientes reintentan al mismo tiempo (thundering herd)
- Límite de reintentos: siempre define un máximo (3-5 reintentos típicamente)
Retry inmediato sin límite puede empeorar el problema al sobrecargar un servicio que ya está luchando.
Pregunta 8
¿Qué son los tres pilares de la observabilidad?
- A) CPU, memoria y disco
- B) Logs, métricas y traces
- C) Alertas, dashboards y reportes
- D) Uptime, latencia y throughput
Ver respuesta
Respuesta: B
Los tres pilares de la observabilidad son:
- Logs: registros textuales de eventos discretos (qué pasó)
- Métricas: valores numéricos agregados en el tiempo (cuánto, cuán rápido)
- Traces: seguimiento de un request a través de múltiples servicios (por dónde pasó)
Juntos, permiten entender el comportamiento de un sistema distribuido. Las alertas, dashboards y reportes son herramientas que consumen estos datos, pero no son pilares en sí mismos.
Pregunta 9
¿Cuál es la diferencia entre disponibilidad 99.9% y 99.99%?
- A) No hay diferencia práctica
- B) 99.9% permite ~8.7 horas de downtime al año; 99.99% permite ~52 minutos
- C) 99.99% requiere microservicios; 99.9% no
- D) 99.99% es imposible de alcanzar
Ver respuesta
Respuesta: B
La diferencia es significativa:
- 99.9% (tres nueves): ~8.7 horas de downtime al año (~43 minutos al mes)
- 99.99% (cuatro nueves): ~52 minutos de downtime al año (~4.3 minutos al mes)
- 99.999% (cinco nueves): ~5.2 minutos de downtime al año
Cada “nueve” adicional requiere inversión exponencialmente mayor en redundancia, monitoreo y automatización. La mayoría de las aplicaciones no necesitan más de tres nueves.
Sección 4: Seguridad
Pregunta 10
¿Dónde debe validarse la autenticación en una arquitectura de microservicios?
- A) Solo en el frontend
- B) En cada microservicio individualmente
- C) En el API Gateway, propagando la identidad a los servicios internos
- D) Solo en la base de datos
Ver respuesta
Respuesta: C
El patrón recomendado es:
- El API Gateway valida el token de autenticación (JWT, session, etc.)
- Si es válido, propaga la identidad del usuario (userId, roles) a los servicios internos via headers
- Los servicios internos confían en la identidad propagada y aplican autorización según sus reglas de negocio
Validar en cada servicio es redundante y costoso. Validar solo en el frontend es inseguro — el backend siempre debe verificar.
Resultados
Cuenta tus respuestas correctas:
| Rango | Nivel | Recomendación |
|---|---|---|
| 9-10 | Avanzado | Estás listo para los retos avanzados |
| 7-8 | Intermedio | Buen nivel — revisa los temas donde fallaste |
| 5-6 | Básico | Repasa las secciones de fundamentos y patrones |
| < 5 | Principiante | Comienza desde el inicio — cada sección te ayudará |
No te preocupes por la puntuación — lo importante es identificar qué temas necesitas reforzar y volver a las secciones correspondientes.