Operaciones y Administración → Dependencias de servicios

Dependencias de servicios

1) Por qué es necesario

Cualquier plataforma de producción es gráfica: los usuarios de → Edge/API → servicios de dominio → cola/stream → DB/caché → proveedores externos (pagos, KYC, proveedores de juegos). El error en una arista del grafo suele «caminar» por toda la red: crecen los retrasos, se disparan los retraídos, se obstruyen las colas, se producen fallos en cascada. El control de dependencias reduce el «radio explosivo» y hace que las liberaciones sean predecibles.

• Ver el gráfico completo de desafíos y entender quién depende de quién.
• Evitar fallos en cascada y una «tormenta de retraídas».
• Planifique las versiones teniendo en cuenta la compatibilidad y la propagación SLO.
• Aumentar MTTR: localice más rápido el verdadero nodo raíz (root cause).

2) Tipos de dependencia

Sincrónico (RPC: NAT/gRPC/GraphQL): conectividad rígida por latencia/disponibilidad. Necesitamos timautas, rompedores, presupuesto para los retiros.
Asincrónico (Event/Stream: Kafka/Rabbit/Pulsar): una conectividad más resistente, pero hay un lag/backlog y una semántica de entrega (at-least-once, idempotency).
Almacenamiento de información (DB/Cache/Object store): recursos compartidos → contenido, límites de connects/IOPS, eviction, replicación.
Proveedores externos (PSP/KYC/proveedores de juegos): cuotas, llamadas de pago, ventanas de servicio, SLA legales.
Quirófanos (lanzamientos, fichflags, confecciones): dependencias indirectas a través de configuraciones, secretos, registro schema.

3) Directorio de servicios y gráfico de dependencias

• Propietarios (Squad/chat/On-call rota), repos, miércoles, artefactos.
• Contratos API (OpenAPI/AsyncAPI), versiones, compatibilidad (back/forward).
• Dependencias entrantes/salientes (upstream/downstream) con tipo (sync/async), criticidad, expectativas de SLO.
• Presupuesto de taimouts/retiros, rompedores, grupos de bulkhead.
• Datos sobre cuotas y límites de integraciones externas.

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO: p99 ≤ 300 ms, 99. 9% uptime.
• Timeout: 200 ms a 'PSP-X', 150 ms a 'user-profile'.
• Retrai: 2 con retraso exponencial, jitter.
• Breaker: abierto en 30 s con 5% de errores/10 s.

4) SLO-propagación y «presupuesto de latencia»

En una cadena de llamadas sincrónicas, el SLO total se forma a partir de la suma de los retrasos y las probabilidades de fallas.

• El presupuesto de la solicitud se divide de arriba a abajo: SLO 500 ms → Edge 50 ms → API 150 ms → servicios de dominio 200 ms → proveedor 100 ms.
• Los taimautas son «más cortos que los internos»: el timaut invocador tiene menos interior total para que los recursos se actualicen en lugar de las llamadas zombies.
• Retrai sólo para códigos/excepciones seguros y con jitter; sin retraerse a los timautas de los cuellos de botella (de lo contrario, «tormenta»).

5) Contratos e interoperabilidad

Versificación de API: SemVer para contratos; cambios backward-compatibles a través de los campos «optional», extensiones del esquema; eliminación - sólo a través del «período deprechate».
Contratos de consumo-controlados (CDC): se lanzan pruebas de consumo (similares a Pactos) contra el proveedor en CI; la liberación se bloquea cuando hay incompatibilidad.
Esquema-registros (Async): versión de topics/eventos, evolución de circuitos (Avro/JSON-Schema), política «can-read-old/can-write-new».

6) Patrones de ingeniería de sostenibilidad

Timeouts: separamos el SLA del negocio de las expectativas técnicas; cada conexión saliente es un tiempo de espera explícito.
Retries + backoff + jitter: no más de 2-3 intentos, dada la idempotencia.
Circuito Breaker: «caída rápida» en la degradación del downstream; muestras half-open.
Bulkhead (aislamiento de pools): para diferentes downstreams, grupos de subprocesos/podas/conexiones individuales.
Rate-limit/Leaky-bucket: para no matar downstreams en picos.
Idempotency & deduplicación: clave de idempotencia a nivel de consulta/mensaje; el abuelo leiter y la cola retray.
Almacenamiento en caché y follbacks: cachés locales/distribuidos, estados de «stale-while-revalidate», degradación de contenido.

outbound:
psp-x:
timeout_ms: 200 retries: 2 retry_on: [5xx, connect_error]
backoff: exponential jitter: true circuit_breaker:
error_rate_threshold: 0. 05 window_s: 10 open_s: 30 pool: dedicated-psp (max_conns: 200)

7) Observabilidad de dependencias

Tracks distribuidos (TraceID, Baggage): ver la ruta de consulta por enlaces; dormidos en las llamadas salientes con las etiquetas 'peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• Mapa de servicios con indicación de color SLO y costillas erróneas.
• «Top N de adicciones problemáticas» en la última semana.
• «Blast radius» es una lista de los servicios que sufrirán en la caída de X.
• Registros de correlación: incluir 'trace _ id '/' span _ id' en los registros.

8) Administración de versiones de dependencia

Dependency-aware pipelines: la liberación del proveedor se bloquea si las pruebas de CDC de los consumidores son rojas.
Incorporación gradual (fichflags): nuevos campos/endointos → para el 1% de los consumidores → 10% → 100%.
Lanzamientos canarios: comprobamos las dependencias clave y el «presupuesto de latencia» sobre la cuota de tráfico.
Compatibilidad de esquemas: el productor escribe 'vNew', los consumers leen 'vOld/vNew'; después de la transición - «recolección de basura» de los campos antiguos.

9) Incidentes y escaladas por gráfico

Identificamos al «verdadero culpable»: una correlación alert - si degradado 'PSP-X', no pagina todo el 'arbusto de pago', sino el dueño de la integración.
Autodegradación: fichflag «modo mínimo» (endpoints menos pesados, bandas cortadas, apagado de fiches no críticos).
Gardas de las cascadas: limitamos el paralelismo, apagamos los retratos en la rama caliente, abrimos el breaker de antemano (pre-abierto).

• Diagnóstico: qué dashboards/métricas, cómo comprobar cuotas/límites.
• Acciones: reducir RPS, cambiar a un proveedor de respaldo, activar temporalmente las respuestas en caché.
• Reversión y validación: devuelva los parámetros, asegúrese de que la norma es p95/p99 y error-rate.

10) Matriz de criticidad de dependencias

• Para los «críticos» - doble proveedor, rompedores, grupos individuales, pruebas de caos.
• Para los «altos», al menos la degradación y el «botón verde» de apagar los fiches.
• Para las «medias/bajas», los límites son para los retiros y el presupuesto de las colas.

11) Proceso: desde el inventario hasta la operación

1. Mapeo del gráfico: recopilar las llamadas reales (tracks) + las dependencias declarativas del directorio.
2. Designar propietarios: para cada servicio e integración externa - on-call responsable.
3. Definir SLO y presupuestos: latencia/errores, timeouts/retray/pools.
4. Formalizar contratos: OpenAPI/AsyncAPI, esquemas y CDC.
5. Incluir patrones de estabilidad: timeouts/retries/circuit/bulkhead.
6. Configurar dashboards y alertas per-dependency.
7. Poner las puertas de liberación: bloque por CDC/compatibilidad/canario.
8. Juegos regulares: experimentos de caos sobre la caída de costillas clave.
9. Postmortemas con enfoque en la comunicación: lo que reforzó la cascada es cómo estrechar el radio.

12) Alertas de dependencia (ideas de reglas)

• `outbound_error_rate{to="X"} > 3% FOR 10m` → warning; `>5% FOR 5m` → critical.
• `outbound_p99_latency{to="X"} > SLO1. 3 FOR 10m` → warning.

• ' circuit _ open {to =» X»} = = 1 FOR 1m' → page al propietario de la integración.

• 'retry _ rate {to = «X «}> baseline2 FOR 5 m '+ 'outbound _ rps> 0' → el riesgo de tormenta.

• `consumer_lag{topic="Y"} growth > threshold FOR 10m` + `hpa at max` → крит.

• ' usage _ quota {provider =» PSP-X «}> 90% window '→ advertencia, autocorrección de rutas.

13) Anti-patrones

«Un grupo común de flujos para todos los downstreams». Total: bloqueo head-of-line. Dividan las balas.
Sin temporizadores/con retratos infinitos. Así es como nace la tormenta.
Retratos ciegos de cirugías no idempotentes. Tomas de cargos/apuestas.
Un «DB compartido» oculto como punto de conectividad. Fuerte competencia y bloqueos.
La versión de la API cambia sin un plan de CDC y deprecat. Coge caídas masivas.
Observabilidad sólo por servicios, no por comunicaciones. No se puede ver dónde está la cadena.

14) Dashboards: conjunto mínimo

Mapa del servicio: mapa interactivo de servicios con métricas de costillas (latency/error/volume).
Upstream/Downstream Overview: para el propietario del servicio, las dependencias entrantes (quién llama), salientes (a quién llamamos), «la parte superior de los problemas».
Dependency Drilldown: tarjeta de comunicación específica: p50/p95/p99, errores por clase, porcentaje de rompedor abierto, retraídas, grupo de conexiones, cuotas/costa.
Release Context: anotaciones de versiones/fichflags en gráficos de dependencia.

15) Lista de verificación de implementación

• Catálogo de servicios con propietarios y contratos (OpenAPI/AsyncAPI).
• Gráfico completo de dependencias de rastreo (actualizar diariamente).
• SLO por servicio y «presupuestos de latencia» a lo largo de la cadena.
• Tiempo de espera explícito, retraídas con jitter, rompedores, aislamiento de bulkhead.
• Pruebas de CDC en CI como una puerta de lanzamiento.
• Dashboards per-dependency y mapa del servicio.
• Alertas en las costillas + suppression por causa raíz.
• Días de juego: caída del proveedor/clúster/topic y verificación de degradación.
• Plan de degradación: qué fichas desactivamos, qué cachés activamos.
• Postmortemas regulares con acciones para reducir la conectividad.

16) KPI de calidad de administración de dependencias

Dependency MTTR: mediana de recuperación a lo largo de la costilla.
Índice Radius de Blast: número medio de servicios afectados por caída de uno.
Coupling Score: la proporción de dependencias sync entre todos; tendencia a la baja.
Tasa de pase de los CDC:% de las liberaciones sin infracción de contrato.
Retry Storms/mes: el valor objetivo es → 0.
Costo de llamadas externas: costo de llamadas externas en 1k RPS (ver efecto de caché/follback).

17) Inicio rápido (impagos)

Timautas: 70-80% del presupuesto del enlace; el tiempo de espera superior de la consulta <suma interna.
Retrai: max 2, sólo en idempotente 5xx/red, con backoff + jitter.
Breaker: el umbral del 5% de errores en 10 s, open = 30 s, half-open muestras.
Bulkhead: grupos dedicados/límites de conexión para cada downstream.
CDC: son obligatorios para todas las API y topics públicas.
Async-preference: donde se puede - ir a eventos/colas (intercambio de tiempo).

18) FAQ

P: ¿Qué es más importante: retraídas o rompecabezas?
A: Ambos. Los retraídos se salvan de fallos de corta duración, el rompecabezas protege contra la degradación permanente y las tormentas.

P: ¿Cómo entender que la conexión es «demasiado frágil»?
R: Alta correlación de errores, bajo margen de tiempo de espera, retraídas frecuentes, sin follbacks/cachés, cadenas largas sincrónicas.

P: ¿Por qué CDC si tenemos pruebas de integración?
R: Los CDC registran las expectativas del consumidor y rompen la liberación del proveedor en caso de incompatibilidad - antes de que el código entre en el código.