Webhooks vs. WebSockets vs. gRPC

Toda aplicação que lê dados de blockchain enfrenta a mesma questão arquitetural: como os dados devem chegar ao seu sistema? Fazer polling em uma API a cada poucos segundos desperdiça computação, perde eventos e adiciona latência. Em vez disso, ao empurrar os dados (push), você precisa escolher um modelo de entrega.

Três protocolos dominam a entrega de dados em tempo real: webhooks, WebSockets e gRPC. Eles não são intercambiáveis. Webhooks notificam seu backend quando algo acontece. WebSockets fazem streaming de dados ao vivo para um navegador. gRPC move dados entre serviços de backend com alta taxa de transferência. Escolher o errado tem um custo que aparece depois: eventos perdidos, computação desperdiçada ou um redesenho do sistema que você não planejou.

O que são webhooks, WebSockets e gRPC?

Os três movem dados de um servidor para sua aplicação sem polling. As semelhanças terminam aí.

Um webhook inverte a direção usual de uma API. Em vez do seu código chamar o servidor, o servidor chama uma URL que você registrou, com um payload JSON, sempre que algo que ele monitora acontece. Webhooks são simples de configurar; a contrapartida é que você não controla o timing nem o formato do que chega.

Um WebSocket é uma conexão TCP persistente entre um cliente e um servidor. Qualquer um dos lados pode enviar pequenos quadros binários a qualquer momento sem reestabelecer a conexão. O protocolo começa como uma requisição HTTP e muda para um socket bruto assim que ambos os lados concordam com o upgrade.

gRPC é um framework de remote procedure call (RPC): um sistema que permite que um serviço chame funções em outro serviço como se estivesse chamando uma função local. Sucessor público do Stubby, o sistema RPC interno do Google, gRPC roda sobre HTTP/2, serializa dados como Protocol Buffers e suporta quatro modos de streaming, incluindo o bidirecional completo. Foi construído para serviços de backend que movem dados estruturados rapidamente entre máquinas, com retries embutidos, propagação de deadline e contratos tipados.

Como funcionam os webhooks?

Webhooks invertem o modelo de API. Você não chama o servidor; o servidor chama você. Você registra uma URL com um provedor, informa quais eventos importam e espera. Quando algo acontece, o provedor faz um POST de JSON para seu endpoint e espera um 2xx em resposta.

O trecho acima é um handler de webhook: ele verifica a assinatura, enfileira o payload e retorna 200. A versão simples acima também é de onde vêm a maioria das interrupções em produção de webhooks. O que separa um handler de brinquedo de um de produção é como ele lida com três coisas que a versão simples faz errado: verificação de assinatura, comportamento de retry e sobrecarga em rajadas.

O primeiro modo de falha é o tratamento fraco de assinatura. O provedor assina cada entrega com HMAC usando um segredo compartilhado (Alchemy usa X-Alchemy-Signature, Stripe usa Stripe-Signature), e seu handler precisa recalcular o HMAC, compará-lo em tempo constante para evitar ataques de timing, e rejeitar qualquer coisa com um timestamp anterior a cinco minutos. Chamar verify() é uma linha; fazer isso corretamente são várias. Pule qualquer etapa e você estará confiando em qualquer processo que conheça a URL do seu endpoint.

O segundo modo de falha é o tratamento não idempotente sob retry. Quando as entregas falham (timeouts, quedas parciais, respostas 5xx), os provedores retentam com backoff exponencial (tipicamente dobrando a partir de um segundo, com jitter, limitado a uma hora) por horas ou dias antes de enviar o payload para uma dead-letter queue. Webhooks garantem entrega pelo menos uma vez, não exatamente uma vez (entrega exatamente uma vez é impossível em sistemas distribuídos), então entregas duplicadas são rotina. Seu handler precisa ser idempotente: processar o mesmo evento duas vezes deve produzir o mesmo resultado que processá-lo uma vez. Rastreie IDs de evento em um armazenamento de deduplicação e retorne 200 em repetições.

O terceiro modo de falha é a sobrecarga em rajada, e é o que quebra sistemas de webhook em escala. Um único evento on-chain pode disparar milhões de entregas simultâneas. Se seu endpoint é o gargalo, a fila de retry do provedor se torna seu atacante de DoS.

Em infraestrutura de blockchain, webhooks alimentam fluxos de trabalho orientados a eventos. Nossos Custom Webhooks suportam monitoramento de atividade de endereço, alertas de transferência de NFT e eventos de smart contract filtrados por GraphQL em mais de 30 chains EVM, além de Solana, todos entregues como callbacks HTTP POST ao seu endpoint.

Como funcionam os WebSockets?

Um WebSocket começa como uma requisição HTTP comum com um cabeçalho Upgrade: websocket. O servidor responde com HTTP 101 (Switching Protocols), e a partir desse ponto a conexão para de falar HTTP. Essa negociação é o handshake do WebSocket. O que resta depois é um socket TCP bruto com uma camada fina de framing por cima: sem cabeçalhos por mensagem, sem ciclo de requisição-resposta.

Remover o HTTP torna os WebSockets drasticamente mais baratos por mensagem. Cada mensagem WebSocket carrega 2-6 bytes de overhead (um bit FIN, opcode e comprimento do payload). Compare isso com HTTP, onde cada requisição inclui centenas de bytes de cabeçalhos. A 100 mensagens por segundo, o overhead do WebSocket é de aproximadamente 600 bytes por segundo, contra 60.000 bytes por segundo para tráfego HTTP equivalente.

Conexões WebSocket são stateful e de longa duração. Qualquer um dos lados pode enviar dados a qualquer momento sem esperar pelo outro. O servidor envia quadros ping periódicos; o cliente responde com quadros pong para provar que a conexão está viva. Sem esses heartbeats, conexões mortas ("zombies") vazam recursos do servidor, e proxies reversos derrubam conexões ociosas após 30-120 segundos.

A contrapartida: você é dono do ciclo de vida da conexão, e esse ciclo tem mais coisas do que parece à primeira vista. Quando uma conexão cai, seu cliente precisa reconectar, e reconectar com backoff exponencial (esperando progressivamente mais tempo entre tentativas), ou milhares de clientes reconectando ao mesmo tempo vão sobrecarregar o servidor. Quando você roda mais de um servidor WebSocket atrás de um load balancer, o load balancer precisa rotear toda reconexão de um determinado cliente de volta para a mesma máquina, porque essa máquina mantém o estado de assinatura do cliente. Essa regra de roteamento tem um nome: afinidade de sessão. E se uma mensagem originada em um servidor precisa chegar a um cliente conectado a outro servidor, os servidores precisam compartilhar estado entre nós. WebSockets te dão o protocolo de transporte; tudo acima disso é você quem constrói.

Para aplicações de blockchain, WebSockets são a interface padrão para assinaturas de eventos ao vivo. O endpoint eth_subscribe da Ethereum empurra novos cabeçalhos de bloco, eventos de log e transações pendentes por uma conexão WebSocket persistente. Nossos Smart WebSockets adicionam assinaturas filtradas com reconexão automática sobre o protocolo base.

Fazer streaming de dados ao vivo para um navegador é o problema que os WebSockets foram construídos para resolver. Antes dos WebSockets, as alternativas (long-polling, server-sent events) ou pagavam o overhead completo do HTTP por mensagem, ou só funcionavam em uma direção. WebSockets te dão uma conexão persistente, de baixo overhead e bidirecional no único lugar onde um socket TCP bruto normalmente não conseguiria existir: o navegador.

Essa clareza também é o seu limite. WebSockets sofrem quando o consumidor não é um navegador, os dados são estruturados, o volume é alto, e você precisa de coisas que WebSockets nunca prometeram: schemas tipados, streams multiplexados, propagação de deadline, backpressure. É para isso que o gRPC foi construído.

Como funciona o gRPC?

O gRPC parte do extremo oposto do espaço de design. Onde webhooks são callbacks HTTP e WebSockets são uma camada fina de framing sobre TCP, gRPC é um framework RPC completo com contratos tipados em seu núcleo. Antes de escrever qualquer lógica de negócio, você escreve um arquivo .proto definindo seu serviço e as mensagens que ele envia e recebe. O compilador de protobuf transforma o arquivo em código de cliente e servidor gerado na sua linguagem (chamados de stubs), então chamar um método remoto no seu código se parece com chamar uma função local.

A camada de transporte é HTTP/2, combinada com Protocol Buffers para serialização. Juntos, eles dão ao gRPC três vantagens sobre uma stack típica de REST + HTTP/1.1 + JSON:

• Multiplexação elimina o head-of-line blocking, o problema do HTTP/1.1 onde uma única resposta lenta segura todas as requisições subsequentes na mesma conexão. Com gRPC, cada chamada roda como um stream HTTP/2 independente compartilhando a mesma conexão TCP. Square é uma das várias equipes de engenharia que migraram tráfego interno serviço a serviço para gRPC para reduzir o overhead de conexão.
• A compressão de cabeçalhos (HPACK) substitui cabeçalhos repetidos por referências compactas. Em tráfego RPC onde o mesmo método, tipo de conteúdo e cabeçalhos de autenticação se repetem a cada chamada, isso reduz o overhead de cabeçalhos em 85-90%.
• Protocol Buffers serializam mensagens em binário compacto em vez de texto. Os payloads são 34% menores que JSON em ambientes não comprimidos, e a deserialização é até 6x mais rápida, dependendo da linguagem. A contrapartida: payloads binários não são legíveis por humanos, então você precisa de ferramentas como grpcurl ou Postman para inspecionar o tráfego.

O gRPC suporta quatro modos de streaming. Unário (uma requisição, uma resposta) funciona como uma chamada de API padrão. Streaming de servidor (uma requisição, muitas respostas) serve para feeds e pushes de dados. Streaming de cliente (muitas requisições, uma resposta) lida com uploads em lote. Streaming bidirecional (ambos os lados enviam independentemente) alimenta interações stateful em tempo real.

O gRPC não é um protocolo de propósito geral. Ele é estreitamente otimizado para serviços de backend que movem dados estruturados a altas taxas entre máquinas que você controla nas duas pontas, e esse nicho focado é onde o custo inicial de escrever schemas e rodar geração de código se paga. O que garante ao gRPC essa posição não é só a codificação binária; são as primitivas de produção embutidas no protocolo. A propagação de deadline transforma cada timeout em um ponto absoluto no tempo que atravessa toda a cadeia de chamadas. Se o Serviço A define um deadline de 5 segundos e chama o Serviço B, que chama o Serviço C, cada salto sabe exatamente quanto tempo resta. Quando o deadline expira, todo o trabalho downstream é cancelado e libera recursos. O controle de fluxo herda do HTTP/2: quando um consumidor lento não consegue acompanhar, o remetente automaticamente desacelera para se ajustar. Isso é backpressure embutido, algo que nem webhooks nem WebSockets oferecem nativamente.

Em Solana, o gRPC alimenta o streaming de dados de mais alta performance disponível. O plugin Yellowstone gRPC (Geyser) carrega diretamente no espaço de memória do validator, captura atualizações de contas e transações antes que elas cheguem ao disco, serializa como protobuf e as envia por streams HTTP/2 persistentes.

Como os três protocolos se comparam em desempenho?

Benchmarks de throughput e latência traçam uma linha clara para comunicação serviço a serviço. A codificação protobuf binária combinada com multiplexação HTTP/2 dá ao gRPC throughput mensuravelmente maior e latência menor que REST sobre HTTP/1.1, especialmente em cargas de trabalho com payloads pequenos e muitas chamadas concorrentes.

WebSockets vencem uma disputa diferente: menor overhead por mensagem para streaming de navegador para servidor. Após o handshake inicial, cada mensagem carrega 2-6 bytes de overhead de framing, e a API WebSocket nativa do navegador lida com a conexão sem proxies ou ferramentas de build.

Webhooks não são projetados para desempenho. Cada entrega é uma requisição HTTP independente com overhead completo de configuração de conexão. Eles resolvem um problema diferente: notificação de eventos assíncrona e confiável, onde simplicidade e compatibilidade importam mais do que throughput.

Os números específicos de blockchain reforçam o padrão. O Yellowstone gRPC do Solana faz streaming de dados com ~5ms de latência de slot; WebSockets nativos entregam em ~10ms; o polling via RPC fica para trás em ~150ms. Cada passo a mais em complexidade de protocolo compra velocidade mensurável.

Quando cada protocolo apresenta problemas?

Webhooks têm dificuldade com eventos de alta frequência. Em centenas de entregas por segundo, o overhead HTTP por callback se torna um gargalo. Eventos em rajada criam problemas de thundering herd: um evento on-chain importante dispara milhões de entregas de webhook simultaneamente, sobrecarregando tanto as filas de retry do provedor quanto os endpoints do consumidor. Webhooks também são estritamente unidirecionais. Qualquer caso de uso que exija comunicação bidirecional precisa de um protocolo diferente. Como descreveu um engenheiro que construiu infraestrutura de webhooks: "webhooks são dolorosos de operar."

WebSockets têm dificuldade em escala. Cada conexão retém recursos do servidor (2-10 KB ociosa, mais quando ativa). Um servidor ajustado lida com mais de 500 mil conexões ociosas, mas a rotatividade de conexões é o verdadeiro gargalo: handshakes TLS consomem de 1.000 a 3.000 por segundo por core de CPU. Quando um servidor reinicia, todo cliente conectado reconecta simultaneamente, criando uma tempestade de reconexão que pode virar uma interrupção completa. No Solana, a implementação padrão de WebSocket "se tornou instável sob carga", degradando em desempenho e desconectando com frequência, o que levou equipes do Solana em direção ao gRPC.

O gRPC tem dificuldade na borda do navegador. Navegadores não conseguem falar gRPC nativamente. O protocolo gRPC-Web preenche a lacuna por meio de um proxy (tipicamente Envoy), mas perde streaming de cliente e streaming bidirecional no processo. Payloads binários protobuf não podem ser inspecionados com curl ou DevTools do navegador, o que torna o gRPC pouco adequado para APIs públicas onde a experiência do desenvolvedor importa. O toolchain do protobuf (definições de schema, geração de código, integração com build) adiciona um custo de configuração significativo para integrações simples.

Como escolher entre webhooks, WebSockets e gRPC?

Comece pelo padrão de comunicação que seu caso de uso exige.

Webhooks são o padrão. Se seu backend precisa saber quando um evento discreto acontece (uma transação confirma, um NFT é transferido, um pagamento é concluído) e a taxa de eventos fica abaixo de algumas centenas por segundo, webhooks são a integração de menor custo que funciona com qualquer linguagem, qualquer framework e qualquer firewall. Sem conexão persistente, sem infraestrutura de streaming, sem SDK de cliente.

Quando a taxa de eventos sobe ou você precisa de dados fluindo em ambas as direções, WebSockets assumem. Pense em tickers de preço ao vivo, atualizações de order book, monitoramento de mempool, dashboards colaborativos: qualquer coisa em que uma conexão persistente com um navegador evita que você sobrecarregue uma API. Suporte nativo no navegador, sem proxy, overhead de quadro medido em bytes.

Escolha gRPC quando precisar de throughput máximo entre serviços de backend. Pipelines de indexer, streaming de dados de validators, comunicação microserviço a microserviço, e qualquer carga de trabalho onde você controla ambas as pontas da conexão se beneficiam de serialização binária, streams multiplexados, contratos tipados e backpressure embutido. A ressalva é o toolchain: schemas protobuf, geração de código, sem suporte nativo no navegador. Vale a pena quando desempenho e confiabilidade superam a complexidade de configuração.

Combine-os quando a arquitetura exigir. Muitos sistemas em produção usam os três: gRPC faz streaming de dados de validators para indexers, WebSockets empurram dados processados para dashboards no navegador, e webhooks notificam sistemas externos sobre eventos discretos. Não há motivo para apostar tudo em um único protocolo.

Construa com dados de blockchain em tempo real na Alchemy

Suportamos os três protocolos em mais de 100 chains.

Nossos Custom Webhooks entregam confirmações de transação, atividade de endereço e eventos de NFT como callbacks HTTP POST com verificação de assinatura HMAC e retries automáticos. Filtros GraphQL permitem que você assine exatamente os eventos de contrato que sua aplicação precisa.

Smart WebSockets oferecem streams eth_subscribe filtrados com reconexão automática e latência reduzida para aplicações de frontend em tempo real.

Para equipes Solana que processam dados de alto volume, nosso streaming Yellowstone gRPC entrega atualizações de contas e transações diretamente da memória do validator com latência abaixo de 10ms.

Os três estão disponíveis no nosso plano gratuito. Sem contratos, sem lista de espera. Cadastre-se e comece a fazer streaming em minutos.

Perguntas frequentes

Qual é a principal diferença entre webhooks, WebSockets e gRPC?

Webhooks são callbacks HTTP unidirecionais para notificações de eventos servidor a servidor; WebSockets fornecem conexões persistentes e bidirecionais entre cliente e servidor; gRPC é um framework RPC sobre HTTP/2 projetado para comunicação serviço a serviço de alta taxa de transferência com contratos tipados.

Quando devo usar webhooks em vez de WebSockets ou gRPC?

Use webhooks quando precisar de notificações de eventos discretos (como confirmações de transação ou transferências de NFT) a uma taxa abaixo de algumas centenas por segundo e não precisar de uma conexão persistente. É a integração mais simples, sem exigir um SDK de cliente especializado ou infraestrutura.

Quando os WebSockets são a melhor escolha?

WebSockets são melhores para streaming contínuo de dados em tempo real para clientes de navegador, como tickers de preço ao vivo, atualizações de order book ou dashboards. Oferecem suporte nativo no navegador e baixo overhead por mensagem (2-6 bytes) após o handshake inicial.

Que problemas o gRPC foi projetado para resolver?

O gRPC é otimizado para serviços de backend que movem dados estruturados a altas taxas, como pipelines de indexer ou streaming de dados de validators. Ele fornece serialização binária, streams multiplexados, contratos tipados via Protocol Buffers, backpressure embutido e propagação de deadline.

Posso usar webhooks, WebSockets e gRPC juntos no mesmo sistema?

Sim, muitos sistemas em produção combinam os três: gRPC para comunicação serviço a serviço de backend, WebSockets para atualizações em tempo real no navegador, e webhooks para notificar sistemas externos sobre eventos discretos. Cada protocolo resolve uma camada arquitetural diferente.

Quais são as diferenças de desempenho entre esses protocolos?

O gRPC entrega a menor latência e o maior throughput por meio de codificação binária e multiplexação HTTP/2; WebSockets oferecem baixo overhead (2-6 bytes por mensagem) para streaming no navegador; webhooks têm o maior custo por mensagem devido ao overhead completo de round-trip HTTP, mas priorizam simplicidade sobre desempenho.

Quais são as principais desvantagens de cada protocolo?

Webhooks têm dificuldade com eventos de alta frequência e tráfego em rajada; WebSockets enfrentam desafios de escala com rotatividade de conexões e tempestades de reconexão do tipo thundering-herd; gRPC exige configuração de toolchain protobuf, não tem suporte nativo no navegador e precisa de um proxy (gRPC-Web) para clientes web.

Como a Alchemy suporta esses protocolos para aplicações de blockchain?

A Alchemy fornece Custom Webhooks para notificações de eventos em mais de 100 chains, Smart WebSockets para streams eth_subscribe filtrados com reconexão automática, e streaming Yellowstone gRPC no Solana entregando atualizações de contas com latência abaixo de 10ms diretamente da memória do validator.