Compatibilidade direta

O que é compatibilidade direta

Compatibilidade direta (forward compatibility) é a capacidade do sistema de trabalhar corretamente com clientes ou dados mais novos do que os que foi projetado originalmente. Mais simples: o servidor antigo não é quebrado quando um novo cliente chega; O consumidor antigo não cai quando recebe uma nova mensagem.

A partir da compatibilidade invertida (quando o novo sistema suporta clientes antigos), o forward é um foco de responsabilidade: nós projetamos protocolos e clientes de modo a «sobreviver» futuras extensões sem um total upgrade de todo o ecossistema.

Princípios básicos

1. Tolerant reader & tolerant writer

Reader ignora campos/cabeçalhos desconhecidos e permite novos valores enum com fallback correto.
Writer não envia nada que o servidor claramente não tenha declarado como suportado (capabilities).

2. Capability negotiation

Compartilhamento explícito de recursos (fici/versões/tipos de mídia) na fase handshake. O cliente adapta seu comportamento à resposta do servidor.

3. Degradação em default

As novas funcionalidades são consideradas opcionais: se o servidor/consoador não as suporta, o cenário ainda será concluído com um mínimo útil (MGC).

4. Núcleo estável (MGC)

O contrato mínimo de garantia está inalterado; As inovações são vividas como extensões.

5. Contratos de erro como parte do protocolo

Os códigos/causas previsíveis («fichas não suportadas», «tipo de mídia desconhecido») permitem ao cliente reverter automaticamente para o modo suportado.

6. Versões sem surpresas

As linhas maiores estão separadas; extensões menores não exigem atualização do servidor/consoador.

Onde isso é particularmente importante

API pública com integração de longa duração (associados, SDK em aplicativos móveis).
Plataformas de eventos com muitos consoadores independentes.
Clientes móveis que se atualizam mais lentamente do que backand.
Edge/EcoT, onde parte do parque de dispositivos raramente é consultada.

Pattern de implementação por estilo

REST/HTTP

• 'Accept'/midiatips com parâmetros (' aplicação/vnd. example. order+json; v=1; profile=risk`).
• 'Preferir: inclusive =...' para blocos opcionais.
• Título 'X-Capabilities: risk _ score, item _ details _ v2'.

• Envia uma solicitação em formato básico, extensões - somente se o servidor confirmar a capabilidade (através de OPÇÕES/desc/lead-endpoint).
• «415/406/501» é automaticamente revertido para o formato/método suportado.
• Resposta do servidor: parâmetros desconhecidos - Ignorar; campos extras - permitidos; o formato de erro está estável ('tipo/código/detail/trace _ id').

gRPC / Protobuf

Serviços estáveis: novos métodos/campos - aditivos; o servidor antigo ignora os campos de consulta desconhecidos.
Função discovery: o método 'GetCapabilities ()' devolve listas de fichas/limites. O cliente não chama «método v2» se o servidor não o tiver declarado.
Streaming: verifique a ordem do conjunto mínimo de mensagens; marca os novos «quadros» com extensões/tipos que o cliente antigo ignorar.

GraphQL

Forward-friendly: novos campos/tipos aparecem no servidor - os clientes antigos simplesmente não os solicitam.
Os palpites são proibidos: o cliente deve manter o padrão (introspecção/codogênico) e não enviar diretrizes/variáveis desconhecidas.
Degradação: se o servidor desconhecer a diretriz/função custômica, o cliente constrói a solicitação sem ela.

Event-driven (Kafka/NATS/Pulsar, Avro/JSON/Proto)

Compatibilidade FORWARD de padrão no registro: Consoadores antigos podem ler mensagens gravadas pelo novo esquema.
Campos aditivos em default, os novos produtores não quebram os antigos consórcios.
Core vs Enriched: O núcleo permanece o mesmo, as novas informações são publicadas em '.enriched' ou como campos opcionais.

Práticas de engenharia

1. Contrato de Consulta Mínima (MGC)

A operação deve ter um «pescoço apertado» que será suportado por todos os servidores há anos.

2. Bandeiras fichas ao nível do contrato

Descreva os ficheiros como «risk _ score», «pricing _ v2», «strong _ idempotency». O cliente inclui-os claramente.

3. Códigos de erro explícitos para «não suportado»

HTTP: `501 Not Implemented`, `415 Unsupported Media Type`, детальные `problem+json`.
gRPC: `UNIMPLEMENTED`/`FAILED_PRECONDITION`.
Events: rota para DLQ s 'reason = unsupported _ função'.

4. Não depender da ordem/lista completa

O cliente deve estar preparado para os novos valores enum, a falta de novos campos e as propriedades «adicionais».

5. Identificadores e formatos estáveis

Não altere o formato de ID/chave de partilha dentro da linha - o que quebra o forward do lado dos leitores.

6. Documentação de leitura automática

Hospedagem de descriptor: OpenAPI/AsyncAPI/Proto descriptors/GraphQL SDL. Os clientes podem verificar o suporte.

Teste de compatibilidade forward

Schema-diff em modo FORWARD/FULL: o novo esquema valida o consumidor/servidor antigo.
Teste de contrato do cliente: O novo cliente é executado contra um servidor antigo com fichas ativas/desligadas.
Golden requests: um conjunto de «novas» solicitações são enviadas para o servidor «antigo»; espera-se uma degradação sem erros críticos.
Chaos/latency: verificação de temporizadores/retrações - o novo cliente deve sobreviver corretamente ao pior SLA do antigo servidor.
Canary: Parte dos novos clientes trabalha com a versão anterior do servidor - coletando telemetria de erros/degradações.

Observabilidade e métricas operacionais

Proporção de solicitações/mensagens com fichas não suportadas e suas reversões automáticas.
Distribuição por versão do cliente (User-Agente/metadados/claims).
Erros 'UNIMPLEMENTED/501/415' e rotas de DLQ com 'unsupported _ função'.
Tempo de degradação: p95/p99 para MGC contra resposta «avançada».

Modos de compatibilidade no registro de esquemas

FORWARD: nova entrada é compatível com o leitor antigo (precisa de default, opção).
FULL: и FORWARD, и BACKWARD; É conveniente para contratos públicos.
Recomendação: para eventos - BACKWARD para produtor e FORWARD para portador (via tolerant reader), para API externo - FULL.

Exemplos

REST (capabilities + degradação)

1. O cliente faz 'GET/meta/capabilities' → '

2. Em 'POST/orders', envia campos básicos; 'risk _ score' não pede porque o servidor não sabe.
3. Se por acaso enviou 'Prefere: inclusive = risk _ score', o servidor responde 200 sem o campo 'risk _ score' (ou 'Preference-Applied: none') - o cliente não cai.

gRPC (discovery)

'GetCapabilities' devolveu a lista de métodos/fichas. O cliente não chama 'CaptureV2' se não estiver presente - em vez disso, usa 'Capture' e converte os dados de entrada para a vista suportada localmente.

Events (FORWARD no registro)

O produtor adicionou o campo 'risk _ score' (nullable em default). A antiga consoante ignora-o. sua lógica usa apenas campos de núcleo estáveis.

Antipattern

Cliente rígido: filtra a resposta em campos whitelist e cai em propriedades desconhecidas.
Fichas implícitas: o cliente começa a enviar uma nova opção sem a verificação de capabilidades.
A mudança de formatos de ID/chave dentro da linha → os antigos servidores/consoantes deixam de entender novas solicitações/mensagens.
Suposições costuradas sobre lista completa de enum (switch sem default).
Logar como controle de fluxo: parsing linhas de erro em vez de códigos de contrato.

Folha de cheque de implementação

• Definido pelo MGC; as novas funcionalidades são marcadas como opcionais.
• Descrito e implementado por capability negotiation (endpoint/metadados/handshake).
• Os clientes ignoram campos desconhecidos e processam corretamente novos enum (fallback).
• Os contratos de erro registram «não suportado» previsivelmente (HTTP/gRPC/Event).
• O registro dos esquemas está configurado em FORWARD/FULL para os artefatos apropriados.
• Automóveis: schema-diff (FORWARD), testes contratuais do cliente contra o servidor antigo, canary.
• Métricas: versão do cliente, falha de fique, proporção de degradação, p95 MGC.
• Documentação/SDK publica uma lista de fichas e exemplos de degradação.

FAQ

O que o forward é diferente do backward na prática?
Backward: O novo servidor não quebra clientes antigos. Forward: o servidor antigo não é quebrado por novos clientes (ou consoante antigo por novas mensagens). O ideal é você alcançar full.

É preciso sempre introduzir capabilities?
Se você espera uma evolução ativa sem lançamentos sincronizados, sim. É mais barato do que manter dezenas de linhas maiores.

Como está a segurança?
Os novos fichas devem exigir scopes/claims individuais. Se o servidor não os suporta, o cliente não deve reduzir a segurança, mas deve abrir mão dos fichas.

É possível adivinhar o suporte do servidor?
Não é desejável. É melhor perguntar claramente (capabilities) ou olhar para midiatip/esquema.

Resultado

Compatibilidade direta é uma disciplina para negociar oportunidades e degradar-se com segurança. Núcleo estável, capability negotion, extensões aditivas e erros previsíveis permitem que novos clientes e dados convivam com servidores e consumidores antigos - sem lançamentos em massa ou migrações noturnas.