Arquitectura de APIs

Un API gateway es el punto único de entrada. Rutea, compone respuestas, resuelve asuntos transversales —TLS, límites de tasa, métricas— y traduce protocolos. Variante: Backends for Frontends, un gateway por tipo de cliente. Cuesta un componente más, un posible cuello de botella y un salto de red, y no debe volverse un lugar donde vivan reglas de negocio.

Service mesh

El plano de datos son proxies desplegados como sidecars, uno por instancia, que interceptan de forma transparente su tráfico entrante y saliente: la aplicación no cambia una línea. Aplican mTLS con identidad de carga de trabajo, reintentos, timeouts, corte de circuito, balanceo, división porcentual de tráfico y telemetría. El plano de control los configura en tiempo de ejecución.

El tráfico norte-sur cruza el borde del clúster; el este-oeste va entre servicios adentro.

Evolucionar sin romper

Se versiona por ruta en la URI, por tipo de medio en el encabezado o por parámetro de consulta, pero la mejor versión es la que no hace falta: cambios aditivos y consumidores tolerantes. Eliminar un campo, cambiar su tipo o cambiar un valor por defecto rompe y exige versión mayor.

Los contract tests dirigidos por el consumidor generan el contrato como efecto del test, y el proveedor lo verifica contra sí mismo: prueban que las formas concuerdan, no que el negocio sea correcto.

Validar el token en el borde no alcanza: cada servicio autoriza por su cuenta, con intercambio de tokens para emitir credenciales internas acotadas.