Me gusta que el profesor haya agregado un servidor MCP como ejemplo detrá del gateway. En la épica que estamos, hay que comenzar a hablar también de arquitectura IA.
Si no saben lo que es un MCP, busquen el curso de Platzi.
En el mundo actual de desarrollo de software, la arquitectura de microservicios ha cambiado la forma en que los equipos colaboran y escalan proyectos. Comprender el papel fundamental del API gateway resulta clave para cualquier profesional interesado en integrar servicios, manejar contratos claros y facilitar la independencia de los equipos.
¿Por qué el API gateway es esencial en una arquitectura de microservicios?
El API gateway actúa como una capa de abstracción entre los clientes y los microservicios. Permite que múltiples equipos trabajen en paralelo, integrando implementaciones diversas sin afectar la experiencia del cliente. Además, los API gateways ayudan a mantener contratos sólidos mientras las implementaciones internas pueden cambiar constantemente.
¿Cómo abstrae el API gateway las implementaciones de microservicios?
¿Qué beneficios ofrece el API gateway en grandes integraciones?
Para proyectos que conectan con múltiples entidades externas, como aduanas y tributos de diferentes países, el API gateway permite:
¿Cómo impacta la ley de Conway en la arquitectura de microservicios?
La ley de Conway establece que los sistemas reflejan la estructura de comunicación de la organización. La colaboración entre equipos de distintas culturas y legalidades termina influyendo en cómo se estructura el software. Los contratos de software—como especificaciones OpenAPI o definiciones de operaciones remotas—garantizan que el trabajo en paralelo siga reglas claras, fundamentales para la independencia de los equipos.
¿Qué precauciones deben tenerse al diseñar contratos de software?
¿Cómo evoluciona el rol del arquitecto en microservicios?
El arquitecto deja de ser un cuello de botella. Ahora, el trabajo y las decisiones se distribuyen entre muchos equipos, cada uno validando que sus reglas y contratos sigan un estándar común. Mantener esta coherencia permite que el sistema escale y que equipos independientes colaboren sin fricciones.
¿Te ha tocado implementar o consumir API gateways en tus proyectos? Comparte tu experiencia y enriquece la conversación.
En el mundo actual de desarrollo de software, la arquitectura de microservicios ha cambiado la forma en que los equipos colaboran y escalan proyectos. Comprender el papel fundamental del API gateway resulta clave para cualquier profesional interesado en integrar servicios, manejar contratos claros y facilitar la independencia de los equipos.
El API gateway actúa como una capa de abstracción entre los clientes y los microservicios. Permite que múltiples equipos trabajen en paralelo, integrando implementaciones diversas sin afectar la experiencia del cliente. Además, los API gateways ayudan a mantener contratos sólidos mientras las implementaciones internas pueden cambiar constantemente.
Para proyectos que conectan con múltiples entidades externas, como aduanas y tributos de diferentes países, el API gateway permite:
La ley de Conway establece que los sistemas reflejan la estructura de comunicación de la organización. La colaboración entre equipos de distintas culturas y legalidades termina influyendo en cómo se estructura el software. Los contratos de software—como especificaciones OpenAPI o definiciones de operaciones remotas—garantizan que el trabajo en paralelo siga reglas claras, fundamentales para la independencia de los equipos.
El arquitecto deja de ser un cuello de botella. Ahora, el trabajo y las decisiones se distribuyen entre muchos equipos, cada uno validando que sus reglas y contratos sigan un estándar común. Mantener esta coherencia permite que el sistema escale y que equipos independientes colaboren sin fricciones.
¿Te ha tocado implementar o consumir API gateways en tus proyectos? Comparte tu experiencia y enriquece la conversación.
Me gusta que el profesor haya agregado un servidor MCP como ejemplo detrá del gateway. En la épica que estamos, hay que comenzar a hablar también de arquitectura IA.
Si no saben lo que es un MCP, busquen el curso de Platzi.
si utilizó un APIM también debería utilizar un api gateway? o un aplication gateway??
🧱 API Gateway como capa de abstracción
El API Gateway actúa como un punto de entrada único que abstrae la complejidad interna de los microservicios. Sus funciones incluyen:
Esto permite que los microservicios mantengan su independencia, mientras el gateway garantiza consistencia en la experiencia externa.
🧠 Evolución del rol del arquitecto

El arquitecto ahora diseña frameworks de decisión, define contratos comunes (OpenAPI, GraphQL, gRPC), y promueve prácticas compartidas como versionado, resiliencia y trazabilidad.
🧩 Experiencias comunes con API Gateways
📦 Herramientas populares

¿Cómo garantizan los contratos el trabajo paralelo?
Los contratos de software funcionan exactamente como los planos de un edificio. Si el equipo de plomería y el equipo de electricidad saben exactamente dónde van a estar las paredes y los conectores (el contrato), ambos pueden trabajar al mismo tiempo sin pisarse las mangueras. En el desarrollo de software, herramientas como OpenAPI o esquemas de gRPC definen estrictamente qué datos entran y qué datos salen.
Cuando estableces estas reglas claras desde el día uno, eliminas la dependencia secuencial. El equipo de frontend puede crear mocks (simulaciones) basados en el contrato y empezar a diseñar las pantallas, mientras el equipo de backend construye la lógica real y la base de datos. Además, esto previene que los cambios de un equipo rompan el código del otro. Si alguien necesita modificar la estructura de una respuesta, el contrato actúa como un escudo protector que obliga a negociar y versionar el cambio, manteniendo la estabilidad de todo el ecosistema.
El API Gateway es una pieza clave en arquitecturas de microservicios, ya que actúa como una capa de abstracción entre los clientes y los servicios internos. Su principal valor es desacoplar las implementaciones, permitiendo que los equipos trabajen de forma independiente mientras mantienen contratos estables hacia el exterior.
Este componente centraliza funciones como autenticación, validación, enrutamiento y composición de servicios, además de soportar múltiples protocolos y tipos de clientes. Patrones como Backend for Frontend permiten adaptar las respuestas según las necesidades específicas de cada interfaz.
En entornos complejos —como integraciones con múltiples entidades externas— el API Gateway simplifica la gestión y asegura consistencia, incluso cuando los microservicios evolucionan internamente. Asimismo, conceptos como la Ley de Conway evidencian que la arquitectura refleja la estructura organizacional, haciendo indispensable definir contratos claros (por ejemplo, con OpenAPI).
En este contexto, el arquitecto adopta un rol más distribuido, promoviendo estándares y coherencia sin centralizar todas las decisiones.
Lo ultimo que comenta el profesor:
"El arquitecto deja de ser un cuello de botella. Ahora, el trabajo y las decisiones se distribuyen entre muchos equipos, cada uno validando que sus reglas y contratos sigan un estándar común. "
Se escucha bonito pero en la practica puede no serlo tanto sino se sigue una buena gobernanza, políticas y metodologias de trabajo.
¿Qué pasa? cada equipo utilizando sus "arquitecturas" a conveniencia, creando microservicios sin documentación, sin una buen estandar de nombres, sin exponerlos a los demas equipos, sin realizar buenas pruebas unitarias, de volumen e integrales, por salir a la carrera, y eso despues lleva una deuda tecnica mucho mas grandes y no digamos al atender incidentes.
Mi recomendación es que siempre tengan checklist o documentación que los equipos se guien, que este un documento o un proceso de creación de microservicios, con SLA de respuesta para no tener cuellos de botellas.
Los microservicios nos aportan mucho a nivel de valor para la entrega de datos pero sino se gestionan bien su creación, mantenimiento, observabilidad puede ser un caos.