Le monde asynchrone, derrière les mêmes portes.

Le plan asynchrone a son contrat, exactement comme le synchrone a l'OpenAPI : contracts.asyncapi charge un AsyncAPI 3.0.0 ou 3.1.0, validé contre le schéma officiel embarqué. Les canaux, leurs messages et leurs schémas viennent du contrat ; une opération send ou receive nomme son courtier par x-flexway-upstream. La porte HTTP est une opération OpenAPI marquée x-flexway-publish ou x-flexway-subscribe.

L'invariant reste le même : publié ou consommé = déclaré. Une opération sans courtier, une porte vers une opération absente ou de l'autre sens, un corps d'un autre schéma que le message ou un message sans schéma JSON (Avro, Protobuf) sont refusés au chargement, tous rapportés d'un coup. Un refus est dit, jamais ignoré.

Un client HTTP, ou un agent par un outil MCP, publie sans embarquer de client de courtier. Le corps est lu en entier dans une borne, vérifié contre le schéma du message, puis enveloppé en CloudEvents 1.0 en mode binaire (structuré sur MQTT 3.1.1). La passerelle répond 202 seulement après l'accusé du courtier : acks=all d'un producteur Kafka idempotent, confirmation AMQP, PUBACK MQTT en QoS 1. Une Idempotency-Key devient l'id de l'évènement, et idempotency: required l'exige (428 sinon).

Le tampon est borné par courtier et par réplique (max_in_flight, 1 024 par défaut) : au-delà, 503 overloaded immédiat, jamais une file qui grossit avec la panne. Un coupe-circuit par courtier donne 503 upstream_unavailable ; un dépassement de budget donne 504 upstream_timeout, qui signifie issue inconnue.

La passerelle s'authentifie au courtier (SASL, mTLS, secrets par référence) ; l'appelant voyage en attributs CloudEvents - tenant toujours, traceparent, authid et authtype seulement si le message les déclare - et un en-tête ce-* fourni par l'appelant est refusé (400). Un message publié par une route REST porte la même ligne d'audit et le même verdict d'autorisation qu'un appel synchrone.

Un navigateur ou un mobile consomme un flux sans parler le protocole du courtier. En SSE, la diffusion est en éventail : un consommateur par canal et par réplique, quel que soit le nombre d'abonnés ; la reprise se fait par Last-Event-ID depuis l'historique en mémoire du canal (history, 64 par défaut), avec 412 au-delà. En WebSocket, la livraison est au moins une fois : la position n'avance qu'après {"ack": "<id>"}, sinon la connexion est fermée après ack_timeout et le message est livré de nouveau.

Un abonné ne reçoit que ce que nomment ses valeurs vérifiées : un paramètre de canal lié (x-flexway-bind: tenant, subject ou claim:<nom>) ou l'attribut tenant filtré sur les en-têtes, jamais sur data. Un canal ni lié, ni filtré, ni déclaré public est refusé au chargement. Un accès public se déclare explicitement (x-flexway-public: true sur l'opération receive) et reste compté par adresse et globalement.

Le tampon est borné par flux, un abonné trop lent est fermé, et max_streams plafonne les flux par appelant et par réplique (429 too_many_streams). L'état durable - positions, groupes - reste dans le courtier : la passerelle reste sans état. L'abonnement d'un agent à un flux par outil MCP est à venir.

Kafka, AMQP 0-9-1 (et AMQPS) et MQTT passent par la même admission que le trafic HTTP : identité, quota, audit, trace. La passerelle atteint un courtier en client, jamais par un écouteur de courtier, et une opération du contrat n'est jamais relayée telle quelle vers un courtier. Les amonts se déclarent par upstreams.*.protocol (kafka, amqp, mqtt), avec brokers, protocol_version et sasl dont le mot de passe est une référence.

À la consommation, les deux modes CloudEvents sont lus selon la règle de chaque liaison : application/cloudevents+json en structuré, binaire sinon. Les erreurs du plan asynchrone sont rendues dans un attribut CloudEvents, comme elles le sont en RFC 9457 sur HTTP. La configuration se recharge à chaud : un client de courtier inchangé est réutilisé, et un client par abonnement coûte des connexions, d'où le plafond max_streams.

Une opération receive peut livrer à une cible déclarée (x-flexway-deliver, amont protocol: webhook). La consommation se fait dans un groupe partagé par les répliques, une réplique par message, au format Standard Webhooks : webhook-id égal à l'id de l'évènement, signature HMAC-SHA256 qui couvre les attributs, deux secrets actifs pour la rotation, corps en CloudEvent structuré. Un partenaire reçoit ainsi les évènements de son tenant sans accès au courtier.

L'adresse est vérifiée à la connexion : boucle locale, lien local et métadonnées du nuage sont toujours refusés, les plages privées seulement avec allow_private, sans proxy ni redirection. Les réessais sont bornés (retries.max, retries.max_delay) et respectent Retry-After, avec un coupe-circuit par cible. La position n'avance qu'après un 2xx ; réessais épuisés ou refus 4xx, l'évènement intact part dans la file de rebut déclarée, avec problemcode et problemstatus, d'où il peut être rejoué.

Une livraison n'a pas d'appelant : un canal lié à un fait d'appelant (subject, claim) ne peut pas être livré par webhook, et une livraison sans tenant ou sans file de rebut est refusée au chargement.

Le plan asynchrone livré médie entre HTTP et les courtiers. Le proxy Kafka natif va plus loin : des clients Kafka branchés directement sur la passerelle, avec des clusters et des sujets virtuels par tenant.

Il s'accompagne d'ACL et de quotas par client Kafka, puis du chiffrement de champs des messages au niveau du proxy. L'état de ces trois fonctionnalités à cette version, lu dans le catalogue du produit, est indiqué ci-dessous.