Morphosis API Gateway
Propuesta de diseño; aún no está lista para producción

Una política, dos puntos de ejecución

Centro de políticas de enrutamiento de tráfico

Explica cómo la cadena de publicación de configuración entrega las políticas y cómo estas guían tanto la selección de la región de entrada como la selección del backend después de la autenticación.

Explica cómo la cadena de publicación de configuración entrega las políticas y cómo estas guían tanto la selección de la región de entrada como la selección del backend después de la autenticación.

7. Diseño de enrutamiento y multirregional

7.1 Modelo de enrutamiento

Cada configuración de ruta debe contener, como mínimo, la siguiente información:

Antes de publicar una ruta, debe superar validación estática: no hay conflicto de rutas, existe el required scope, el servicio destino está registrado, la solicitud de escritura declara explícitamente la política de idempotencia y el tiempo de espera tiene un límite.

7.1.1 Lógica de decisión del centro de política de enrutamiento de tráfico

El centro de política de enrutamiento de tráfico mantiene una política versionada, pero se ejecuta en dos ubicaciones. El primer punto de ejecución está en la entrada global y solo selecciona la región de entrada; el segundo está en el gateway regional y elige el backend después de completar la validación de API Key y la coincidencia de ruta. La indicación de comerciante o plataforma usada durante la entrada no está autenticada y solo puede reducir el conjunto de candidatos de entrada, no conceder permisos; después de entrar en una región debe volver a verificarse con la identidad validada, y si no coincide se debe seleccionar de nuevo un backend elegible o rechazar la solicitud.

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 34, "rankSpacing": 38, "htmlLabels": true}}}%% flowchart TB PUBLISHED["Política publicada<br/>primary_region · allowed_regions<br/>capacidad de servicio · failover_mode"] --> CENTER["Centro de política de enrutamiento de tráfico<br/>compila política versionada y vista de estado de ejecución"] RUNTIME["Señales de ejecución<br/>salud de región / backend · retraso de réplica · estado de writer"] --> CENTER HINT["Indicación de enrutamiento no autenticada<br/>solo para elegir entrada · no concede permisos"] --> EDGE_FILTER["Punto de ejecución 1 · filtro de candidatos de entrada<br/>allowed_regions · cumplimiento · salud regional"] EDGE_FILTER --> MODE{"Modo de política configurado"} MODE --> FIXED["Línea base de diseño · preferencia fija<br/>sin cambio automático"] MODE --> FAILOVER["Línea base de diseño · principal-reserva<br/>solo cambia a una región de reserva elegible"] MODE --> MULTI["Opción recomendada · desactivada por defecto<br/>peso / proximidad dentro de allowed_regions<br/>solo lecturas sin estado"] FIXED --> ENTRY["Decisión de región de entrada<br/>detener resolución o devolver 503 al fallar<br/>según el producto de tráfico global"] FAILOVER --> ENTRY MULTI --> ENTRY ENTRY --> AUTH["Entrada regional<br/>validación de API Key + coincidencia de ruta"] AUTH --> CONTEXT["Comerciante validado<br/>route + request_class"] CANDIDATES["Punto de ejecución 2 · filtro de candidatos tras autenticación<br/>servicio desplegado · saludable<br/>configuración con antigüedad acotada según la sección 10.4"] CONTEXT --> CLASS{"Tipo de solicitud"} CANDIDATES --> CLASS CLASS -->|"lectura"| READ_GATE["Control de lectura<br/>retraso de réplica no supera el umbral<br/>la señal de estado no ha vencido"] CLASS -->|"escritura"| WRITE_GATE["Control de escritura<br/>prioridad al writer actual<br/>interregional requiere idempotencia global · restricción única · cambio explícito de primario"] READ_GATE --> ELIGIBLE{"¿Quedan candidatos tras el filtro?"} WRITE_GATE --> ELIGIBLE ELIGIBLE -->|"sí"| DECISION["Salida de decisión de ruta<br/>target · reason_code · policy_version"] ELIGIBLE -->|"no"| REJECT["Fallo cerrado<br/>devolver 503"] CENTER -.->|"política de entrada y vista de estado"| EDGE_FILTER CENTER -.->|"política regional y vista de estado"| CANDIDATES classDef input fill:#F4F7FB,stroke:#72849A,color:#253954,stroke-width:1.5px classDef policy fill:#EDF8F3,stroke:#16835E,color:#124D3B,stroke-width:1.5px classDef baseline fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:1.5px classDef proposed fill:#FFF7E8,stroke:#B7791F,color:#62420F,stroke-width:1.5px classDef runtime fill:#FFFFFF,stroke:#4F79A7,color:#18212F,stroke-width:1.5px classDef reject fill:#FFF2EC,stroke:#C7582B,color:#6B2812,stroke-width:1.5px class PUBLISHED,RUNTIME,HINT,CONTEXT input class CENTER,EDGE_FILTER,MODE,CANDIDATES,CLASS,ELIGIBLE policy class FIXED,FAILOVER,ENTRY,AUTH,READ_GATE,WRITE_GATE,DECISION baseline class MULTI proposed class REJECT reject

La reunión solo confirmó redundancia multirregional y capacidad de enrutamiento, no un algoritmo concreto. Los modos de preferencia fija y principal-reserva son la línea base de diseño actual; activo-activo por peso o proximidad es una opción recomendada, desactivada por defecto, que solo puede utilizarse para lecturas sin estado dentro del conjunto de regiones permitido explícitamente por el comerciante. El punto de ejecución 1 no puede determinar con fiabilidad el tipo de solicitud antes de autenticar; si una solicitud de escritura llega a una región que no es writer, el punto de ejecución 2 debe seleccionar el writer actual o devolver 503, y no debe producir escritura interregional sin control. El producto de tráfico global, el punto de terminación TLS y el mecanismo de indicaciones de enrutamiento previas a la autenticación todavía no están determinados, por lo que el comportamiento ante fallo de entrada y las entradas disponibles deben confirmarse tras la selección técnica. El reason_code del diagrama solo se escribe en el registro interno de decisiones y en auditoría, no se divulga externamente; los errores externos siguen la sección 6.2.

7.2 Pertenencia regional del comerciante

Para cada comerciante se mantiene una región preferida explícita y una lista de regiones disponibles. El centro de política de enrutamiento de tráfico publica la política en los dos puntos de ejecución: la entrada global envía preferentemente la solicitud del comerciante a la región preferida y el gateway dentro de la región elige el backend después de autenticar según la partición de enrutamiento del comerciante, capacidad del servicio y tipo de solicitud.

La pertenencia regional del comerciante no puede depender únicamente de la geolocalización de resolución DNS, porque la salida del comerciante, el punto de acceso de red privada y la ubicación de los datos de negocio pueden ser diferentes. La política regional debe configurarse y auditarse desde el plano de control.

7.3 Conmutación por fallo regional

  1. El plano de datos del gateway se despliega en varias zonas de disponibilidad; el balanceo de carga regional retira automáticamente una instancia o zona de disponibilidad que falle.
  2. Después de confirmar que una región no está disponible, el punto de ejecución de entrada del centro de políticas de enrutamiento solo cambia a los comerciantes autorizados para conmutación por fallo a una región de reserva ya configurada y elegible.
  3. Al integrar cada plataforma se debe declarar el nivel de coherencia de lectura, retraso máximo permitido de réplica, método de recopilación de la señal de estado de réplica y antigüedad máxima de la señal. Una solicitud de lectura solo puede conmutar automáticamente por fallo cuando el retraso de réplica informado por la región de reserva no supera el máximo permitido por la ruta y la señal de estado no está vencida.
  4. Una solicitud de escritura de pagos solo puede reintentarse entre regiones cuando la plataforma de backend proporciona una clave de idempotencia global, restricción única y un mecanismo explícito para cambiar la región principal de escritura.
  5. Si el backend no satisface los requisitos previos de escritura interregional, el gateway devuelve un 503 trazable y está prohibido escribir simultáneamente en dos regiones.
  6. Después de recuperar la región, se realiza una reversión controlada: primero se validan la versión de configuración de autorización y el estado de réplica del backend, y luego se restaura el tráfico gradualmente.

7.4 Límite de múltiples bases de datos de backend

La reunión mencionó que Zero Confirmation puede usar tres bases de datos y BPS podría adoptar un modelo similar en el futuro. El gateway solo conserva metadatos de "a qué servicio de backend debe enrutarse un comerciante o partición"; no posee conexiones a bases de datos particionadas de negocio ni divide SQL de negocio.

Cada plataforma debe garantizar por sí misma:

  1. La coherencia entre el mapeo de particiones y la topología de bases de datos de negocio.
  2. Restricciones únicas e idempotencia de las escrituras de transacciones.
  3. Replicación interregional, punto de recuperación y tiempo de recuperación.
  4. La publicación al gateway de nuevos endpoints de servicio disponibles o una nueva versión de ruta después de completar el cambio de base de datos.

7.5 Recuperación ante desastres del plano de control

El plano de control unificado adopta modo activo y de reserva entre regiones; en cualquier momento solo se permite escribir a una región de plano de control:

  1. PostgreSQL utiliza replicación síncrona dentro de la región primaria y replica WAL de forma asíncrona hacia la región de reserva; el objetivo de retraso de réplica en la región de reserva no supera 60 segundos.
  2. La versión del plano de control utiliza una versión de dos partes (epoch, sequence) y se compara en orden lexicográfico. Las confirmaciones normales solo incrementan sequence; al cambiar la región primaria primero se incrementa epoch y luego se inicia un nuevo sequence, y se prohíbe que dos regiones produzcan versiones comparables pero divergentes.
  3. Antes de promover la región primaria o de que la reserva asuma el control, se debe confirmar mediante vallado de base de datos gestionada o arrendamiento de consenso que el nodo primario anterior perdió permiso de escritura; si no se puede completar el vallado, está prohibido asumir el control.
  4. Una instancia del plano de control solo puede aceptar escrituras administrativas mientras posea un arrendamiento válido de escritura única, y falla en modo cerrado inmediatamente cuando vence el arrendamiento.
  5. Si el retraso de aplicación WAL de la región de reserva supera 60 segundos, deja de aceptar escrituras ordinarias de configuración y emite alerta; las operaciones de denegación de emergencia utilizan el canal break-glass de la sección 10.3.
  6. Después de asumir el control, primero recupera eventos Outbox no publicados y después publica una instantánea completa de configuración con el nuevo epoch; todas las regiones rechazan cualquier evento del epoch anterior.
  7. Se recomienda un objetivo de tiempo de recuperación del plano de control de 30 minutos y un objetivo de punto de recuperación de configuración de 1 minuto; ambos objetivos deben validarse mediante ejercicios trimestrales de recuperación.

Un fallo del plano de control no debe interrumpir las solicitudes del plano de datos que ya cargaron configuración, pero pausará la creación ordinaria de Key, rotación, cambio de Scope, cambio de IP y publicación de rutas.