Las 30 preguntas y respuestas principales de las entrevistas sobre microservicios en 2026

1. ¿Qué son los microservicios y en qué se diferencian de la arquitectura monolítica?

Respuesta: Los microservicios son un estilo arquitectónico que estructura una aplicación como una colección de pequeños servicios autónomos modelados en torno a un dominio empresarial. Cada microservicio se ejecuta en su propio proceso y se comunica a través de mecanismos ligeros (normalmente API HTTP/REST o colas de mensajes).

Diferencias clave con la arquitectura monolítica:

• Despliegue: Los microservicios se implementan de forma independiente; Los monolitos se despliegan como unidades individuales.
• Escalabilidad: Los servicios individuales se escalan de forma independiente en lugar de escalar toda la aplicación
• Tecnología: Cada microservicio puede utilizar diferentes pilas de tecnología; los monolitos utilizan una pila unificada
• Aislamiento de fallas: Una falla en el servicio no bloquea todo el sistema en microservicios
• Estructura del equipo: Los equipos pequeños y multifuncionales poseen servicios propios frente a los equipos grandes que administran todo el código base

2. ¿Cuáles son las principales ventajas y desventajas de los microservicios?

Respuesta:

Ventajas:

• Implementación independiente y ciclos de lanzamiento más rápidos
• Diversidad tecnológica: elija las mejores herramientas para cada servicio
• Mejor aislamiento de fallas y resiliencia del sistema
• Más fácil de entender y mantener bases de código más pequeñas
• Escalabilidad: escale solo los servicios que lo necesiten

Desventajas:

• Mayor complejidad operativa (monitoreo, implementación, redes)
• Desafíos del sistema distribuido (latencia de red, coherencia de datos)
• Difícil probar flujos de trabajo de un extremo a otro
• La gestión de datos entre servicios se vuelve compleja
• Requiere una sólida cultura de DevOps y automatización de la infraestructura

3. ¿Qué es el patrón de base de datos por servicio y por qué es importante?

Respuesta: El patrón Base de datos por servicio significa que cada microservicio posee su base de datos privada a la que otros servicios no pueden acceder directamente. Los servicios interactúan únicamente a través de API bien definidas.

Por qué es importante:

• Garantiza un acoplamiento flexible: los servicios siguen siendo independientes
• Permite que cada servicio elija la tecnología de base de datos óptima
• Evita dependencias no deseadas mediante el acceso directo a la base de datos.
• Permite escalamiento independiente y evolución del esquema.
• Desafío: Requiere gestión de transacciones distribuidas y eventual coherencia

4. ¿Cuáles son los principales patrones de comunicación entre microservicios?

Respuesta: Existen dos estilos de comunicación principales:

1. Comunicación Sincrónica (Solicitud-Respuesta):

• API REST/HTTP: las más comunes, simples y sin estado
• gRPC: alto rendimiento, protocolo binario, escritura segura
• GraphQL: consulta de datos flexible, reduce la recuperación excesiva
• Úselo cuando: El cliente necesita una respuesta inmediata

2. Comunicación asincrónica (basada en eventos):

• Colas de mensajes (RabbitMQ, AWS SQS): entrega punto a punto
• Flujos de eventos (Kafka, AWS Kinesis): publicación-suscripción, registro de eventos
• Úselo cuando: operaciones de disparar y olvidar, servicios de desacoplamiento, necesidades de alto rendimiento

5. ¿Cómo funciona una API Gateway y por qué utilizar una?

Respuesta: Una puerta de enlace API es un servidor que actúa como un punto de entrada único para los clientes a una arquitectura de microservicios. Envía solicitudes a los servicios apropiados, agrega respuestas y maneja inquietudes transversales.

Funciones clave:

• Enrutamiento y composición de solicitudes (agregando múltiples llamadas de servicio)
• Aplicación de autenticación y autorización
• Limitación y estrangulamiento de velocidad
• Traducción de protocolo (HTTP a gRPC, REST a cola de mensajes)
• Almacenamiento en caché y transformación de respuestas
• Ejemplos populares: Kong, AWS API Gateway, Azure API Management, Netflix Zuul

6. Explique el patrón de descubrimiento de servicios.

Respuesta: Service Discovery permite que los servicios se encuentren y se comuniquen entre sí dinámicamente sin direcciones codificadas. Esencial en entornos de nube donde las instancias de servicio aumentan o disminuyen y las direcciones IP cambian con frecuencia.

Dos patrones principales:

• Descubrimiento del lado del cliente: El cliente consulta el registro del servicio (Consul, Eureka, etcd) y realiza el equilibrio de carga.
• Descubrimiento del lado del servidor: Registro de consultas del balanceador de carga y solicitudes de rutas (Servicios de Kubernetes, AWS ELB)

7. ¿Qué es el patrón del disyuntor?

Respuesta: Circuit Breaker evita que un servicio intente repetidamente ejecutar una operación que probablemente falle, lo que le permite fallar rápidamente y recuperarse sin problemas.

Estados:

• Cerrado: Funcionamiento normal, las solicitudes pasan
• Abierto: Las fallas exceden el umbral, las solicitudes fallan inmediatamente sin llamar al servicio
• Medio abierto: Después del tiempo de espera, las solicitudes limitadas prueban si el servicio se recupera

Bibliotecas de ejemplo: Netflix Hystrix, Resilience4j, Polly (.NET)

8. Describa el patrón Saga para transacciones distribuidas.

Respuesta: Una Saga es una secuencia de transacciones locales donde cada transacción actualiza datos dentro de un solo servicio. Si un paso falla, las transacciones de compensación deshacen los cambios anteriores.

Dos enfoques de coordinación:

• Coreografía: Los servicios publican eventos, otros escuchan y reaccionan (descentralizados, complejos de depurar)
• Orquestación: El orquestador central le dice a los servicios qué hacer (centralizado, más fácil de monitorear)

Ejemplo: pedido de comercio electrónico que requiere pago, inventario, coordinación de envío

9. ¿Cuál es el patrón de migración del higo estrangulador?

Respuesta: El patrón Strangler Fig reemplaza gradualmente los sistemas monolíticos heredados al construir gradualmente nuevos microservicios alrededor de los bordes y desviar el tráfico de la funcionalidad anterior.

Pasos:

1. Identificar el contexto acotado en monolito para extraer
2. Cree un nuevo microservicio que implemente la misma funcionalidad
3. Dirigir el tráfico a través de la fachada/proxy al nuevo servicio
4. Monitorear y validar el comportamiento del nuevo servicio
5. Elimine el código antiguo del monolito una vez que esté seguro
6. Repita hasta que el monolito se descomponga por completo.

10. ¿Qué es el patrón CQRS (Command Query Responsibility Segregation)?

Respuesta: CQRS separa las operaciones de lectura (consulta) y escritura (comando) en diferentes modelos. Los comandos modifican el estado; Las consultas recuperan datos sin efectos secundarios.

Beneficios:

• Optimice las bases de datos de lectura y escritura de forma independiente (por ejemplo, PostgreSQL para escrituras, Elasticsearch para lecturas)
• Escale las cargas de trabajo de lectura y escritura de manera diferente
• Simplifique los modelos de dominio complejos separando las preocupaciones
• A menudo se combina con Event Sourcing para obtener un seguimiento de auditoría completo

11. ¿Cómo se maneja la coherencia de los datos entre microservicios?

Respuesta: Los microservicios suelen adoptar una coherencia eventual en lugar de una coherencia sólida debido a las bases de datos distribuidas.

Estrategias:

• Arquitectura basada en eventos: Los servicios publican eventos cuando cambian los datos; otros actualizan sus bases de datos consumiendo eventos
• Patrón de saga: Coordinar transacciones distribuidas con acciones compensatorias.
• CQRS + abastecimiento de eventos: Almacene eventos como fuente de verdad, reconstruya modelos de lectura
• Composición de la API: Consulta múltiples servicios y agrega datos en API Gateway
• Evitar: Compromiso de dos fases (2PC) en todos los servicios: demasiado lento y frágil en sistemas distribuidos

12. ¿Qué es el abastecimiento de eventos?

Respuesta: Event Sourcing almacena el estado de la aplicación como una secuencia de eventos inmutables en lugar de instantáneas del estado actual. El estado actual se obtiene reproduciendo eventos.

Ventajas:

• Registro de auditoría completo: conozca el estado exacto en cualquier momento
• Habilitar consultas temporales y depuración
• Admite arquitecturas basadas en eventos de forma natural
• Facilite la creación de múltiples modelos de lectura a partir del mismo flujo de eventos.

Desafíos: Evolución del esquema de eventos, mayor almacenamiento, complejidad de consultas

13. ¿Cómo se implementan uniones entre microservicios con bases de datos separadas?

Respuesta: Dado que los servicios poseen bases de datos independientes, las uniones SQL tradicionales son imposibles. Utilice estos patrones:

• Composición de la API: Consulta múltiples servicios a través de sus API y combina resultados en el código de la aplicación o API Gateway
• CQRS con vistas materializadas: Mantener la base de datos de lectura desnormalizada actualizada a través de eventos de múltiples servicios
• Replicación de datos: Los servicios almacenan en caché los datos de referencia necesarios de otros servicios (coherencia comercial para el rendimiento)
• Reconsiderar los límites: Si se necesitan uniones frecuentes, los servicios pueden ser demasiado granulares; considere fusionarlos

14. ¿Qué papel juegan los contenedores (Docker) en los microservicios?

Respuesta: Los contenedores proporcionan paquetes livianos y portátiles que encapsulan microservicios con todas las dependencias, lo que garantiza un comportamiento consistente durante el desarrollo, las pruebas y la producción.

Beneficios clave:

• Aislamiento: cada servicio se ejecuta en su propio contenedor con recursos dedicados
• Consistencia: el mismo contenedor se ejecuta de manera idéntica en todas partes
• Eficiencia: inicio más rápido que las máquinas virtuales, mayor densidad
• Control de versiones: imágenes de Docker etiquetadas con versiones para revertir
• Ecosistema: se integra con orquestadores como Kubernetes, mallas de servicios y canalizaciones de CI/CD.

15. ¿Cómo admite Kubernetes la arquitectura de microservicios?

Respuesta: Kubernetes es una plataforma de orquestación de contenedores que automatiza la implementación, el escalado y la gestión de microservicios.

Capacidades principales:

• Descubrimiento de servicios y equilibrio de carga: DNS integrado y equilibrio de carga para servicios
• Escala automática: Horizontal Pod Autoscaler escala los servicios según la CPU/métricas personalizadas
• Autosanación: Reinicia contenedores fallidos y reemplaza instancias en mal estado
• Actualizaciones continuas: Implemente nuevas versiones sin tiempo de inactividad
• Gestión de configuración: ConfigMaps y secretos para configuraciones específicas del entorno
• Gestión de recursos: Límites de CPU/memoria y solicitudes por servicio

16. ¿Qué es una Service Mesh y cuándo usaría una?

Respuesta: Una Service Mesh es una capa de infraestructura dedicada que maneja la comunicación, la seguridad y la observabilidad de servicio a servicio sin cambiar el código de la aplicación.

Implementaciones populares: Istio, Linkerd, Cónsul Connect

Características:

• Gestión del tráfico (equilibrio de carga, reintentos, disyuntores, tiempos de espera)
• Seguridad (TLS mutua, autenticación, autorización)
• Observabilidad (seguimiento distribuido, métricas, registro)
• División del tráfico para implementaciones canary y pruebas A/B

Úselo cuando: Gestionar comunicaciones complejas entre servicios a escala (normalmente más de 10 servicios)

17. Explique las estrategias de implementación Azul-Verde y Canarias.

Respuesta:

Despliegue Azul-Verde:

• Ejecute dos entornos de producción idénticos (Azul = actual, Verde = nueva versión)
• Implemente una nueva versión en Green, pruébela minuciosamente
• Cambie el tráfico de azul a verde instantáneamente mediante el equilibrador de carga
• Mantenga Blue funcionando para una reversión rápida si surgen problemas

Despliegue canario:

• Implementar una nueva versión para un pequeño subconjunto de usuarios (p. ej., 5 %)
• Monitorear métricas (tasas de error, latencia, KPI comerciales)
• Aumente gradualmente el tráfico a la nueva versión si es estable
• Revertir inmediatamente si se detectan problemas

18. ¿Cómo se monitorean los microservicios en producción?

Respuesta: La observabilidad de los microservicios requiere tres pilares:

1. Métricas:

• Recopile datos de series temporales: tasas de solicitudes, tasas de error, latencias (método RED)
• Utilización de recursos: CPU, memoria, disco, red.
• Herramientas: Prometheus + Grafana, Datadog, New Relic, CloudWatch

2. Registros:

• El registro centralizado agrega registros de todos los servicios
• El registro estructurado (JSON) permite buscar y filtrar
• Herramientas: ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Loki

3. Seguimiento distribuido:

• Realice un seguimiento de las solicitudes a través de los límites del servicio con ID de correlación
• Visualice las dependencias de servicios y los cuellos de botella de latencia
• Herramientas: Jaeger, Zipkin, AWS X-Ray, OpenTelemetry

19. ¿Qué es el rastreo distribuido y por qué es fundamental?

Respuesta: El seguimiento distribuido rastrea una única solicitud de usuario a medida que fluye a través de múltiples microservicios, capturando tiempos y metadatos para cada salto.

Por qué crítico:

• Identificar qué servicio causa tiempos de respuesta lentos
• Errores de depuración que abarcan múltiples servicios
• Comprender las dependencias de servicios y los patrones de llamadas
• Detectar fallos en cascada y reintentar tormentas

Implementación: Cada servicio propaga el ID de seguimiento y el ID de tramo en los encabezados de solicitud; El sistema de seguimiento (Jaeger/Zipkin) agrega tramos en una visualización de seguimiento completa.

20. ¿Cómo se manejan las cascadas de fallas en los microservicios?

Respuesta: Las cascadas de fallas ocurren cuando un servicio fallido hace que fallen los servicios dependientes. Estrategias de prevención:

• Disyuntores: Evite llamadas a servicios defectuosos, falle rápidamente
• Tiempos de espera: Establezca tiempos de espera agresivos para evitar el agotamiento del grupo de subprocesos
• Mamparas: Aislar recursos (grupos de subprocesos, conexiones) por dependencia
• Limitación de tasa: Proteja los servicios de picos de tráfico abrumadores
• Degradación elegante: Devolver datos almacenados en caché/predeterminados en lugar de errores cuando sea posible
• Controles de salud: Kubernetes elimina las instancias en mal estado del equilibrio de carga

21. ¿Cómo se implementa la autenticación y autorización en microservicios?

Respuesta:

Autenticación (¿Quién eres?):

• API Gateway maneja la autenticación inicial (OAuth 2.0, OpenID Connect)
• Emitir tokens JWT que contengan identidades de usuario y reclamos
• Los servicios validan la firma JWT sin llamar al servicio de autenticación (sin estado)

Autorización (¿Qué puedes hacer?):

• Incrustar roles/permisos de usuario en reclamos JWT
• Cada servicio aplica reglas de autorización basadas en reclamos.
• Utilice el motor de políticas centralizado (OPA - Open Policy Agent) para reglas complejas
• Autenticación de servicio a servicio: claves mTLS o API administradas por la malla de servicios

22. ¿Qué es mTLS (Mutual TLS) y por qué usarlo?

Respuesta: Mutual TLS requiere que tanto el cliente como el servidor presenten certificados para la autenticación, estableciendo conexiones cifradas y autenticadas entre microservicios.

Beneficios:

• Cifrado: todo el tráfico entre servicios cifrado en tránsito
• Autenticación: Los servicios prueban la identidad con certificados.
• Seguridad Zero-Trust: nunca confíe únicamente en la ubicación de la red
• Cumplimiento: Cumple con los requisitos reglamentarios para la protección de datos.

Las mallas de servicios (Istio, Linkerd) automatizan la gestión y rotación de certificados, lo que hace que mTLS sea práctico a escala.

23. ¿Cómo se protegen los microservicios de los ataques DDoS?

Respuesta:

• Limitación de velocidad de puerta de enlace API: Limitar solicitudes por usuario/dirección IP por ventana de tiempo
• Protección DDoS del proveedor de la nube: Escudo de AWS, protección DDoS de Azure, Cloudflare
• Cortafuegos de aplicaciones web (WAF): Filtrar solicitudes maliciosas en el borde
• Escala automática: Ampliar temporalmente para absorber los picos de tráfico
• Disyuntores y mamparos: Evitar que el agotamiento de los recursos se propague
• Almacenamiento en caché: Las cachés CDN reducen la carga en los servicios de origen

24. ¿Qué es el patrón Backends for Frontends (BFF)?

Respuesta: BFF crea servicios backend separados optimizados para clientes frontend específicos (web, móvil, IoT) en lugar de forzar una API genérica en todos los clientes.

Por qué es útil:

• Las aplicaciones móviles necesitan cargas útiles más pequeñas que los navegadores web
• Diferentes clientes requieren una lógica de agregación de datos diferente
• Los equipos frontend pueden personalizar su mejor amiga sin afectar a los demás
• Evita la sobrecarga de API Gateway única con lógica específica del cliente

25. Explica el patrón Sidecar.

Respuesta: Un Sidecar es un contenedor auxiliar implementado junto al contenedor de la aplicación principal en el mismo pod, que proporciona funcionalidad auxiliar sin modificar el código de la aplicación.

Usos comunes:

• Registro: Sidecar reenvía registros al sistema centralizado
• Proxying: los sidecars de malla de servicio (Envoy) manejan la gestión del tráfico
• Monitoreo: Sidecar exporta métricas a Prometheus
• Configuración: Sidecar sincroniza archivos de configuración desde una fuente externa

Ejemplo: Istio inyecta el proxy sidecar Envoy en cada pod para control del tráfico y observabilidad.

26. ¿Cómo se versionan las API de microservicios?

Respuesta:

• Versiones de URI: /api/v1/users frente a /api/v2/users (enrutamiento claro y explícito)
• Versiones de encabezado: Aceptar: application/vnd.company.v1+json (URI más limpios)
• Parámetro de consulta: /api/users?version=2 (rara vez recomendado)
• Versionado semántico: Utilice major.minor.patch para API internas
• Estrategia de desaprobación: Admite versiones antiguas durante el período de gracia, advierte a los clientes y desaparece gradualmente

Mejores prácticas: Mantener la compatibilidad con versiones anteriores cuando sea posible; Introduzca nuevas versiones solo para cambios importantes.

27. ¿Cuáles son las implicaciones del teorema CAP para los microservicios?

Respuesta: El teorema de CAP establece que los sistemas distribuidos pueden garantizar solo dos de tres propiedades: coherencia, disponibilidad y tolerancia de partición.

Para microservicios:

• Las particiones de red (P) son inevitables en los sistemas distribuidos; deben tolerarse
• La compensación se produce entre coherencia y disponibilidad durante las particiones.
• Sistemas CP: Prefiere la coherencia (p. ej., transacciones financieras): rechace las escrituras durante la partición
• Sistemas AP: Prefiere disponibilidad (por ejemplo, feeds de redes sociales): acepta datos obsoletos durante la partición

La mayoría de las arquitecturas de microservicios eligen AP (consistencia eventual) porque la disponibilidad es fundamental para la experiencia del usuario.

28. ¿Cómo se prueban los microservicios de forma eficaz?

Respuesta: Pirámide de pruebas adaptada para microservicios:

1. Pruebas Unitarias (70%):

• Pruebe funciones/clases individuales de forma aislada
• Rápido, confiable, ejecutado en proceso de CI

2. Pruebas de Integración (20%):

• Servicio de prueba con base de datos real, colas de mensajes.
• Utilice Docker Compose para el entorno de prueba
• Simule dependencias de servicios externos con herramientas como WireMock, Pact

3. Pruebas de Contrato:

• Verificar contratos API entre servicios (contratos impulsados ??por el consumidor)
• Herramientas: Pacto, Contrato Spring Cloud

4. Pruebas de extremo a extremo (10%):

• Pruebe flujos de trabajo de usuario completos en todos los servicios
• Ejecutar en un entorno de prueba, minimizar debido a la fragilidad.

29. ¿Cuándo NO deberías utilizar microservicios?

Respuesta: Los microservicios añaden una complejidad que puede superar los beneficios en estos escenarios:

• Equipos pequeños: Menos de 5 a 10 desarrolladores no pueden gestionar los gastos operativos
• Aplicaciones simples: Las aplicaciones CRUD sin dominios complejos no necesitan descomposición
• DevOps inmaduros: Sin CI/CD, la supervisión, la automatización y los microservicios se vuelven inmanejables
• Límites poco claros: Si no puede identificar límites de servicio claros, comience con un monolito modular
• Acoplamiento apretado: Los servicios que cambian constantemente juntos probablemente deberían permanecer juntos
• Startups tempranas: Al iterar rápidamente sobre la adecuación del producto al mercado, Monolith acelera el desarrollo

Recomendación: Comience con un monolito bien estructurado y migre a microservicios cuando la complejidad justifique los gastos generales.

30. ¿Cómo maneja la gestión de la configuración en los microservicios?

Respuesta:

• Servidores de configuración centralizados: Spring Cloud Config, Cónsul, almacén de parámetros de AWS Systems Manager
• Variables de entorno: Principio de aplicación de 12 factores: inyectar configuración en tiempo de ejecución a través de env vars
• ConfigMaps y secretos de Kubernetes: Desacoplar la configuración de las imágenes del contenedor
• Banderas de características: Configuración dinámica sin redistribución (LaunchDarkly, Unleash)
• Versionado: Almacene la configuración en Git con código para control de versiones y reversión
• Actualización dinámica: Los servicios recargan los cambios de configuración sin reiniciar (Spring Cloud Bus)

Mejores prácticas: Nunca codifique la configuración; externalizar todo lo específico del entorno.