---
title: "Webhooks vs. WebSockets vs. gRPC"
description: "Tres protocolos dominan la entrega de datos en tiempo real. Así es como se diferencian webhooks, WebSockets y gRPC, cuándo falla cada uno y cómo elegir entre ellos."
---

# Webhooks vs. WebSockets vs. gRPC

<ImageBlock
  src="https://media.alchemy.com/webhooks-vs-websockets-vs-grpc.png"
  alt="Gráfico de portada que compara webhooks, WebSockets y gRPC para la entrega de datos en tiempo real"
  width={1920}
  height={900}
  priority
/>

Toda aplicación que lee datos de blockchain enfrenta la misma pregunta arquitectónica: ¿cómo deben llegar los datos a tu sistema? Si haces polling a una API cada pocos segundos, desperdicias cómputo, pierdes eventos y agregas latencia. Si en cambio envías los datos por push, tienes que elegir un modelo de entrega.

Tres protocolos dominan la entrega de datos en tiempo real: [webhooks](https://www.alchemy.com/overviews/what-is-a-webhook), [WebSockets](https://www.alchemy.com/overviews/what-is-a-websocket) y gRPC. No son intercambiables. Los webhooks notifican a tu backend cuando algo sucede. Los WebSockets transmiten datos en vivo a un navegador. gRPC mueve datos entre servicios de backend con alto throughput. Elegir el equivocado tiene un costo que aparece después: eventos perdidos, cómputo desperdiciado, o un rediseño de sistema que no planeabas.

## ¿Qué son los webhooks, los WebSockets y gRPC?

Los tres mueven datos de un servidor a tu aplicación sin polling. Ahí terminan las similitudes.

Un [webhook](https://www.alchemy.com/webhooks) invierte la dirección habitual de una API. En lugar de que tu código llame al servidor, el servidor llama a una URL que registraste, con un payload JSON, cada vez que ocurre algo que le importa. Los webhooks son simples de configurar; el trade-off es que no controlas el timing ni la forma de lo que llega.

Un [WebSocket](https://www.alchemy.com/smart-websockets) es una conexión TCP persistente entre un cliente y un servidor. Cualquiera de los dos lados puede enviar pequeños frames binarios en cualquier momento sin volver a establecer la conexión. El protocolo comienza como una solicitud HTTP y cambia a un socket sin procesar una vez que ambos lados acuerdan hacer el upgrade.

gRPC es un framework de remote procedure call (RPC): un sistema que le permite a un servicio llamar funciones en otro servicio como si estuviera llamando a una función local. Sucesor público de Stubby, el sistema de RPC interno de Google, gRPC corre sobre HTTP/2, serializa datos como Protocol Buffers y soporta cuatro modos de streaming, incluyendo bidireccional completo. Está construido para servicios de backend que mueven datos estructurados rápidamente entre máquinas, con reintentos integrados, propagación de deadlines y contratos tipados.

<EmbeddedTable
  table={{
    columns: [
      { key: "dimension", width: 180, title: "Dimension", dataType: "object" },
      { key: "webhooks", width: 220, title: "Webhooks", dataType: "object" },
      { key: "websockets", width: 220, title: "WebSockets", dataType: "object" },
      { key: "grpc", width: 240, title: "gRPC", dataType: "object" },
    ],
    data: [
      {
        dimension: { title: "Protocolo", tooltip: "", icon: "" },
        webhooks: { title: "Callbacks HTTP POST", tooltip: "", icon: "" },
        websockets: { title: "TCP persistente (<a href=\"https://www.rfc-editor.org/rfc/rfc6455.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6455</a>)", tooltip: "", icon: "" },
        grpc: { title: "HTTP/2 + <a href=\"https://protobuf.dev/\" target=\"_blank\" rel=\"noopener noreferrer\">Protocol Buffers</a>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        dimension: { title: "Dirección", tooltip: "", icon: "" },
        webhooks: { title: "Servidor a receptor (unidireccional)", tooltip: "", icon: "" },
        websockets: { title: "Bidireccional", tooltip: "", icon: "" },
        grpc: { title: "Bidireccional (4 modos de streaming)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        dimension: { title: "Modelo de conexión", tooltip: "", icon: "" },
        webhooks: { title: "Sin estado (nueva solicitud por evento)", tooltip: "", icon: "" },
        websockets: { title: "Con estado (persistente)", tooltip: "", icon: "" },
        grpc: { title: "Con estado (persistente, multiplexada)", tooltip: "", icon: "" },
        id: 2,
      },
      {
        dimension: { title: "Formato de datos", tooltip: "", icon: "" },
        webhooks: { title: "JSON", tooltip: "", icon: "" },
        websockets: { title: "JSON o binario", tooltip: "", icon: "" },
        grpc: { title: "Protobuf (binario)", tooltip: "", icon: "" },
        id: 3,
      },
      {
        dimension: { title: "Overhead por mensaje", tooltip: "", icon: "" },
        webhooks: { title: "500-2,000 bytes (encabezados HTTP)", tooltip: "", icon: "" },
        websockets: { title: "2-6 bytes", tooltip: "", icon: "" },
        grpc: { title: "Frame de 5 bytes + encabezados comprimidos", tooltip: "", icon: "" },
        id: 4,
      },
      {
        dimension: { title: "Soporte en navegador", tooltip: "", icon: "" },
        webhooks: { title: "N/A (del lado del servidor)", tooltip: "", icon: "" },
        websockets: { title: "Nativo (99%+)", tooltip: "", icon: "" },
        grpc: { title: "Requiere proxy gRPC-Web", tooltip: "", icon: "" },
        id: 5,
      },
      {
        dimension: { title: "Garantía de entrega", tooltip: "", icon: "" },
        webhooks: { title: "Al menos una vez (con reintentos)", tooltip: "", icon: "" },
        websockets: { title: "Ninguna integrada", tooltip: "", icon: "" },
        grpc: { title: "Reintentos configurables + deadlines", tooltip: "", icon: "" },
        id: 6,
      },
      {
        dimension: { title: "Mejor para", tooltip: "", icon: "" },
        webhooks: { title: "Notificaciones de eventos", tooltip: "", icon: "" },
        websockets: { title: "UIs de navegador en tiempo real", tooltip: "", icon: "" },
        grpc: { title: "Pipelines de servicio a servicio", tooltip: "", icon: "" },
        id: 7,
      },
    ],
  }}
/>

## ¿Cómo funcionan los webhooks?

Los webhooks invierten el modelo de API. No llamas al servidor; el servidor te llama a ti. Registras una URL con un proveedor, le indicas qué eventos importan, y esperas. Cuando algo sucede, el proveedor hace POST de JSON a tu endpoint y espera un 2xx como respuesta.

<CodeSnippet
  language="javascript"
  code={`app.post('/webhook', (req, res) => {
  const sig = req.headers['x-alchemy-signature'];
  if (!verify(sig, req.rawBody, SECRET)) return res.status(401).end();
  queue.enqueue(req.body);
  res.status(200).end();
});`}
/>

El fragmento de arriba es un handler de webhook: verifica la firma, encola el payload y devuelve 200. La versión simple de arriba es también de donde vienen la mayoría de las caídas de webhooks en producción. Lo que separa un handler de juguete de uno de producción es cómo maneja tres cosas que la versión simple hace mal: verificación de firma, comportamiento de reintentos y sobrecarga por ráfagas.

El primer modo de fallo es un manejo débil de la firma. El proveedor firma con HMAC cada entrega usando un secreto compartido (Alchemy usa `X-Alchemy-Signature`, Stripe usa `Stripe-Signature`), y tu handler tiene que recalcular el HMAC, compararlo en tiempo constante para evitar ataques de timing, y rechazar cualquier cosa con un timestamp de más de cinco minutos de antigüedad. Llamar a `verify()` es una línea; hacerlo correctamente son varias. Sáltate un paso y estarás confiando en cualquier proceso que conozca la URL de tu endpoint.

El segundo modo de fallo es un manejo no idempotente bajo reintentos. Cuando las entregas fallan (timeouts, caídas parciales, respuestas 5xx) los proveedores reintentan con backoff exponencial (típicamente duplicando desde un segundo, con jitter, con tope de una hora) durante horas o días antes de enviar el payload a una dead-letter queue. Los webhooks garantizan entrega al menos una vez, no exactamente una vez ([entregar exactamente una vez es imposible en sistemas distribuidos](https://en.wikipedia.org/wiki/Two_Generals%27_Problem)), así que las entregas duplicadas son rutinarias. Tu handler tiene que ser idempotente: procesar el mismo evento dos veces debe producir el mismo resultado que procesarlo una vez. Registra los IDs de evento en un store de deduplicación y devuelve 200 en las repeticiones.

El tercer modo de fallo es la sobrecarga por ráfagas, y es el que rompe los sistemas de webhooks a escala. Un solo evento on-chain puede disparar millones de entregas simultáneas. Si tu endpoint es el cuello de botella, la cola de reintentos del proveedor se convierte en tu atacante de DoS.

En infraestructura de blockchain, los webhooks impulsan flujos de trabajo basados en eventos. Nuestros [Custom Webhooks](https://www.alchemy.com/docs/reference/notify-api-quickstart) soportan monitoreo de actividad de direcciones, alertas de transferencia de NFT y eventos de smart contract filtrados con GraphQL en más de 30 chains EVM además de Solana, todo entregado como callbacks HTTP POST a tu endpoint.

## ¿Cómo funcionan los WebSockets?

Un WebSocket comienza como una solicitud HTTP simple con un encabezado `Upgrade: websocket`. El servidor responde con HTTP 101 (Switching Protocols), y a partir de ese punto la conexión deja de hablar HTTP. Esa negociación es el handshake de WebSocket. Lo que queda después es un socket TCP sin procesar con una capa delgada de framing encima: sin encabezados por mensaje, sin ciclo de solicitud-respuesta.

Eliminar HTTP hace que los WebSockets sean dramáticamente más baratos por mensaje. Cada mensaje de WebSocket lleva [2-6 bytes de overhead](https://websocket.org/guides/websocket-protocol/) (un bit FIN, un opcode y la longitud del payload). Compara eso con HTTP, donde cada solicitud incluye cientos de bytes de encabezados. A 100 mensajes por segundo, el overhead de WebSocket es de aproximadamente 600 bytes por segundo frente a 60,000 bytes por segundo para tráfico HTTP equivalente.

<CodeSnippet
  language="javascript"
  code={`const ws = new WebSocket('wss://eth-mainnet.g.alchemy.com/v2/KEY');
ws.send(JSON.stringify({
  jsonrpc: '2.0', id: 1, method: 'eth_subscribe',
  params: ['newHeads']
}));
ws.on('message', (data) => handleBlock(JSON.parse(data)));`}
/>

Las conexiones [WebSocket](https://www.alchemy.com/docs/reference/webhook-types) tienen estado y son de larga duración. Cualquiera de los dos lados puede enviar datos en cualquier momento sin esperar al otro. El servidor envía frames de ping periódicos; el cliente responde con frames de pong para demostrar que la conexión sigue viva. Sin estos heartbeats, las conexiones muertas ("zombies") filtran recursos del servidor, y los proxies inversos matan conexiones inactivas después de 30-120 segundos.

El trade-off: tú eres dueño del ciclo de vida de la conexión, y ese ciclo de vida tiene más de lo que parece a primera vista. Cuando una conexión se cae, tu cliente tiene que reconectarse, y reconectarse con backoff exponencial (esperando progresivamente más tiempo entre reintentos) o miles de clientes reconectándose a la vez saturarán el servidor. Cuando corres más de un servidor WebSocket detrás de un load balancer, este tiene que enrutar cada reconexión de un cliente dado de vuelta a la misma máquina, porque esa máquina tiene el estado de suscripción del cliente. Esa regla de enrutamiento tiene nombre: session affinity. Y si un mensaje que se origina en un servidor necesita llegar a un cliente conectado a otro servidor, los servidores tienen que compartir estado entre nodos. Los WebSockets te dan el protocolo de cable; todo lo que va encima es responsabilidad tuya construirlo.

Para aplicaciones de blockchain, los [WebSockets](https://www.youtube.com/watch?v=hM1cf_7O2VY) son la interfaz estándar para suscripciones a eventos en vivo. El [endpoint eth_subscribe](https://www.alchemy.com/docs/reference/eth-subscribe) de Ethereum envía los headers de nuevos bloques, eventos de log y transacciones pendientes a través de una conexión WebSocket persistente. Nuestros [Smart WebSockets](https://www.alchemy.com/smart-websockets) agregan suscripciones filtradas con reconexión automática sobre el protocolo base.

Transmitir datos en vivo a un navegador es el problema que los WebSockets fueron construidos para resolver. Antes de los WebSockets, las alternativas (long-polling, server-sent events) pagaban el overhead completo de HTTP por mensaje o solo funcionaban en una dirección. Los WebSockets te dan una conexión persistente, bidireccional y de bajo overhead en el único lugar donde un socket TCP sin procesar normalmente no puede vivir: el navegador.

Esa claridad es también su límite. Los WebSockets tienen problemas cuando el consumidor no es un navegador, los datos son estructurados, el volumen es alto, y necesitas cosas que los WebSockets nunca prometieron: esquemas tipados, streams multiplexados, propagación de deadlines, backpressure. Para eso fue construido gRPC.

## ¿Cómo funciona gRPC?

gRPC parte del extremo opuesto del espacio de diseño. Donde los webhooks son callbacks HTTP y los WebSockets son una capa delgada de framing sobre TCP, gRPC es un framework de RPC completo con contratos tipados en su núcleo. Antes de escribir cualquier lógica de negocio, escribes un archivo `.proto` que define tu servicio y los mensajes que envía y recibe. El compilador de protobuf convierte el archivo en código de cliente y servidor generado en tu lenguaje (llamado stubs), de modo que llamar a un método remoto en tu código se ve como llamar a una función local.

<CodeSnippet
  language="protobuf"
  code={`service Geyser {
  rpc Subscribe(stream SubscribeRequest)
    returns (stream SubscribeUpdate);
}`}
/>

La capa de transporte es HTTP/2, combinada con Protocol Buffers para la serialización. Juntos le dan a gRPC tres ventajas sobre un stack típico de REST + HTTP/1.1 + JSON:

- La multiplexación elimina el head-of-line blocking, el problema de HTTP/1.1 donde una sola respuesta lenta retiene a todas las solicitudes posteriores en la misma conexión. Con gRPC, cada llamada corre como un stream HTTP/2 independiente que comparte la misma conexión TCP. Square es uno de los muchos equipos de ingeniería que [migró tráfico interno de servicio a servicio a gRPC](https://grpc.io/about/) para reducir el overhead de conexiones.
- La compresión de encabezados (HPACK) reemplaza encabezados repetidos con referencias compactas. En tráfico de RPC donde el mismo método, tipo de contenido y encabezados de autenticación se repiten en cada llamada, esto [reduce el overhead de encabezados en un 85-90%](https://www.digitalocean.com/community/tutorials/http-1-1-vs-http-2-what-s-the-difference).
- Protocol Buffers serializa mensajes en binario compacto en lugar de texto. Los payloads son un 34% más pequeños que JSON en entornos sin compresión, y la deserialización es [hasta 6 veces más rápida](https://auth0.com/blog/beating-json-performance-with-protobuf/), dependiendo del lenguaje. El trade-off: los payloads binarios no son legibles para humanos, así que necesitas herramientas como grpcurl o Postman para inspeccionar el tráfico.

gRPC soporta cuatro modos de streaming. Unario (una solicitud, una respuesta) funciona como una llamada de API estándar. Server streaming (una solicitud, muchas respuestas) es adecuado para feeds y envíos de datos. Client streaming (muchas solicitudes, una respuesta) maneja cargas por lotes. El streaming bidireccional (ambos lados envían de forma independiente) impulsa interacciones en tiempo real con estado.

gRPC no es un protocolo de propósito general. Está optimizado específicamente para servicios de backend que mueven datos estructurados a tasas altas entre máquinas que controlas en ambos extremos, y ese nicho específico es donde el costo inicial de escribir esquemas y ejecutar generación de código se justifica. Lo que le da a gRPC esa posición no es solo la codificación binaria; son las primitivas de producción integradas en el protocolo. La [propagación de deadlines](https://grpc.io/docs/guides/deadlines/) convierte cada timeout en un punto absoluto en el tiempo que atraviesa toda la cadena de llamadas. Si el Servicio A establece un deadline de 5 segundos y llama al Servicio B, que a su vez llama al Servicio C, cada salto sabe exactamente cuánto tiempo queda. Cuando el deadline expira, todo el trabajo downstream se cancela y libera recursos. El [control de flujo](https://grpc.io/docs/guides/flow-control/) se hereda de HTTP/2: cuando un consumidor lento no puede seguir el ritmo, el emisor automáticamente reduce la velocidad para ajustarse. Eso es backpressure integrado, algo que ni los webhooks ni los WebSockets ofrecen de forma nativa.

En [Solana, gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc) impulsa el streaming de datos de mayor rendimiento disponible. El [plugin Yellowstone gRPC](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview) (Geyser) se carga directamente en el espacio de memoria del validador, captura actualizaciones de cuentas y transacciones antes de que lleguen al disco, las serializa como protobuf, y las envía a través de streams HTTP/2 persistentes.

## ¿Cómo se comparan los tres protocolos en rendimiento?

Los benchmarks de throughput y latencia trazan una línea clara para la comunicación de servicio a servicio. La codificación binaria de protobuf sumada a la multiplexación de HTTP/2 le da a gRPC un throughput medible más alto y una latencia más baja que REST sobre HTTP/1.1, especialmente en cargas de trabajo con payloads pequeños y muchas llamadas concurrentes.

Los WebSockets ganan una competencia distinta: el menor overhead por mensaje para streaming de navegador a servidor. Después del handshake inicial, cada mensaje lleva 2-6 bytes de overhead de framing, y la API nativa de WebSocket del navegador maneja la conexión sin proxies ni herramientas de build.

Los webhooks no están diseñados para el rendimiento. Cada entrega es una solicitud HTTP independiente con overhead completo de configuración de conexión. Resuelven un problema distinto: notificación de eventos asíncrona y confiable, donde la simplicidad y la compatibilidad importan más que el throughput.

<EmbeddedTable
  table={{
    columns: [
      { key: "metric", width: 200, title: "Metric", dataType: "object" },
      { key: "webhooks", width: 220, title: "Webhooks", dataType: "object" },
      { key: "websockets", width: 220, title: "WebSockets", dataType: "object" },
      { key: "grpc", width: 260, title: "gRPC", dataType: "object" },
    ],
    data: [
      {
        metric: { title: "Latencia por mensaje", tooltip: "", icon: "" },
        webhooks: { title: "La más alta (round-trip HTTP completo)", tooltip: "", icon: "" },
        websockets: { title: "Baja (frame de 2-6 bytes)", tooltip: "", icon: "" },
        grpc: { title: "La más baja (binario + multiplexado)", tooltip: "", icon: "" },
        id: 0,
      },
      {
        metric: { title: "Techo de throughput", tooltip: "", icon: "" },
        webhooks: { title: "Limitado por el overhead de HTTP", tooltip: "", icon: "" },
        websockets: { title: "Alto para un solo stream", tooltip: "", icon: "" },
        grpc: { title: "El más alto (streams multiplexados)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        metric: { title: "Costo de serialización", tooltip: "", icon: "" },
        webhooks: { title: "Solo JSON", tooltip: "", icon: "" },
        websockets: { title: "JSON o binario", tooltip: "", icon: "" },
        grpc: { title: "<a href=\"https://auth0.com/blog/beating-json-performance-with-protobuf/\" target=\"_blank\" rel=\"noopener noreferrer\">Protobuf: hasta 6 veces más rápido que JSON</a>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        metric: { title: "Configuración de conexión", tooltip: "", icon: "" },
        webhooks: { title: "Por evento (o reutilización de conexión)", tooltip: "", icon: "" },
        websockets: { title: "Una vez, luego persistente", tooltip: "", icon: "" },
        grpc: { title: "Una vez, luego persistente + multiplexada", tooltip: "", icon: "" },
        id: 3,
      },
      {
        metric: { title: "Backpressure", tooltip: "", icon: "" },
        webhooks: { title: "Ninguno (el receptor absorbe o falla)", tooltip: "", icon: "" },
        websockets: { title: "Ninguno integrado", tooltip: "", icon: "" },
        grpc: { title: "Integrado (control de flujo de HTTP/2)", tooltip: "", icon: "" },
        id: 4,
      },
    ],
  }}
/>

Las cifras específicas de blockchain refuerzan el patrón. El Yellowstone gRPC de Solana transmite datos con una latencia de slot de ~5ms; los WebSockets nativos entregan a ~10ms; el polling de RPC se rezaga a ~150ms. Cada paso hacia arriba en complejidad de protocolo compra velocidad medible.

## ¿Cuándo falla cada protocolo?

Los webhooks tienen problemas con eventos de alta frecuencia. A cientos de entregas por segundo, el overhead de HTTP por callback se convierte en un cuello de botella. Los eventos en ráfaga crean problemas de thundering herd: un evento on-chain importante dispara millones de entregas de webhook simultáneamente, saturando tanto las colas de reintentos del proveedor como los endpoints de los consumidores. Los webhooks también son estrictamente unidireccionales. Cualquier caso de uso que requiera comunicación bidireccional necesita un protocolo distinto. Como [lo describió](https://brandur.org/webhooks) un ingeniero que construyó infraestructura de webhooks: "los webhooks son dolorosos de operar".

Los WebSockets tienen problemas a escala. Cada conexión ocupa recursos del servidor (2-10 KB en reposo, más cuando está activa). Un servidor bien ajustado maneja [500K+ conexiones inactivas](https://websocket.org/guides/connection-limits/), pero el churn de conexiones es el verdadero cuello de botella: los handshakes TLS consumen entre 1,000 y 3,000 por segundo por núcleo de CPU. Cuando un servidor se reinicia, todos los clientes conectados se reconectan simultáneamente, creando una tormenta de reconexiones que puede escalar hasta una caída completa. En Solana, la implementación estándar de WebSocket "se volvió poco confiable bajo carga", degradándose en rendimiento y desconectándose con frecuencia, lo que impulsó a los equipos de Solana hacia gRPC.

gRPC tiene problemas en el borde del navegador. Los navegadores no pueden hablar gRPC de forma nativa. El [protocolo gRPC-Web](https://github.com/grpc/grpc-web) cierra la brecha mediante un proxy (típicamente Envoy), pero pierde el streaming de cliente y el streaming bidireccional en el proceso. Los payloads binarios de protobuf no pueden inspeccionarse con curl o las DevTools del navegador, lo que hace que gRPC sea una mala opción para APIs públicas donde la experiencia del desarrollador importa. El toolchain de protobuf (definiciones de esquema, generación de código, integración de build) agrega un costo de configuración considerable para integraciones simples.

## ¿Cómo deberías elegir entre webhooks, WebSockets y gRPC?

Empieza por el patrón de comunicación que requiere tu caso de uso.

Los webhooks son la opción por defecto. Si tu backend necesita saber cuándo ocurre un evento discreto (una transacción se confirma, un NFT se transfiere, un pago se completa) y la tasa de eventos se mantiene bajo unos pocos cientos por segundo, los webhooks son la integración de menor costo que funciona con cualquier lenguaje, cualquier framework y cualquier firewall. Sin conexión persistente, sin infraestructura de streaming, sin SDK de cliente.

Cuando la tasa de eventos aumenta o necesitas datos fluyendo en ambas direcciones, los WebSockets toman el relevo. Piensa en tickers de precios en vivo, actualizaciones de order book, monitoreo de mempool, dashboards colaborativos: cualquier cosa donde una conexión persistente a un navegador te evite estar golpeando una API. Soporte nativo de navegador, sin proxy, overhead de frame medido en bytes.

Elige gRPC cuando necesites el máximo throughput entre servicios de backend. Pipelines de indexers, streaming de datos de validadores, comunicación de microservicio a microservicio, y cualquier carga de trabajo donde controles ambos extremos de la conexión se benefician de serialización binaria, streams multiplexados, contratos tipados y backpressure integrado. La trampa está en el toolchain: esquemas protobuf, generación de código, sin soporte nativo de navegador. Vale la pena cuando el rendimiento y la confiabilidad pesan más que la complejidad de configuración.

Combínalos cuando la arquitectura lo exija. Muchos sistemas en producción usan los tres: gRPC transmite datos de validadores a indexers, los WebSockets envían datos procesados a dashboards de navegador, y los webhooks notifican a sistemas externos sobre eventos discretos. No hay razón para apostar todo a un solo protocolo.

<EmbeddedTable
  table={{
    columns: [
      { key: "useCase", width: 280, title: "Use case", dataType: "object" },
      { key: "protocol", width: 180, title: "Recommended protocol", dataType: "object" },
      { key: "why", width: 320, title: "Why", dataType: "object" },
    ],
    data: [
      {
        useCase: { title: "Alertas de confirmación de transacción", tooltip: "", icon: "" },
        protocol: { title: "Webhooks", tooltip: "", icon: "" },
        why: { title: "Eventos discretos, integración simple, entrega al menos una vez", tooltip: "", icon: "" },
        id: 0,
      },
      {
        useCase: { title: "Feed de precios en vivo en una UI de trading", tooltip: "", icon: "" },
        protocol: { title: "WebSockets", tooltip: "", icon: "" },
        why: { title: "Datos continuos al navegador, baja latencia, bidireccional", tooltip: "", icon: "" },
        id: 1,
      },
      {
        useCase: { title: "Pipeline de datos de validador de Solana", tooltip: "", icon: "" },
        protocol: { title: "gRPC", tooltip: "", icon: "" },
        why: { title: "Máximo throughput, serialización binaria, backpressure", tooltip: "", icon: "" },
        id: 2,
      },
      {
        useCase: { title: "Suscripciones a nuevos bloques de Ethereum", tooltip: "", icon: "" },
        protocol: { title: "WebSockets", tooltip: "", icon: "" },
        why: { title: "Interfaz estándar eth_subscribe, compatible con navegador", tooltip: "", icon: "" },
        id: 3,
      },
      {
        useCase: { title: "Comunicación de microservicios de backend", tooltip: "", icon: "" },
        protocol: { title: "gRPC", tooltip: "", icon: "" },
        why: { title: "Contratos tipados, multiplexación, propagación de deadlines", tooltip: "", icon: "" },
        id: 4,
      },
      {
        useCase: { title: "Callbacks de integración con terceros", tooltip: "", icon: "" },
        protocol: { title: "Webhooks", tooltip: "", icon: "" },
        why: { title: "Compatibilidad HTTP universal, sin conexión persistente", tooltip: "", icon: "" },
        id: 5,
      },
    ],
  }}
/>

## Construye con datos de blockchain en tiempo real en Alchemy

Soportamos los tres protocolos en [más de 100 chains](https://www.alchemy.com/rpc).

Nuestros [Custom Webhooks](https://www.alchemy.com/webhooks) entregan confirmaciones de transacciones, actividad de direcciones y eventos de NFT como callbacks HTTP POST con verificación de firma HMAC y reintentos automáticos. Los filtros de GraphQL te permiten suscribirte exactamente a los eventos de contrato que tu aplicación necesita.

Los [Smart WebSockets](https://www.alchemy.com/smart-websockets) proveen streams filtrados de eth_subscribe con reconexión automática y latencia reducida para aplicaciones frontend en tiempo real.

Para equipos de Solana que procesan datos de alto volumen, nuestro [streaming Yellowstone gRPC](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview) entrega actualizaciones de cuentas y transacciones directamente desde la memoria del validador con latencia de menos de 10 ms.

Los tres están disponibles en nuestro plan gratuito. Sin contratos, sin lista de espera. [Regístrate](https://dashboard.alchemy.com/signup) y empieza a transmitir en minutos.

## Preguntas frecuentes

### ¿Cuál es la principal diferencia entre webhooks, WebSockets y gRPC?

Los webhooks son callbacks HTTP unidireccionales para notificaciones de eventos entre servidores; los WebSockets proveen conexiones persistentes y bidireccionales entre cliente y servidor; gRPC es un framework de RPC sobre HTTP/2 diseñado para comunicación de servicio a servicio de alto throughput con contratos tipados.

### ¿Cuándo debería usar webhooks en lugar de WebSockets o gRPC?

Usa webhooks cuando necesites notificaciones de eventos discretos (como confirmaciones de transacciones o transferencias de NFT) a una tasa menor a unos pocos cientos por segundo y no requieras una conexión persistente. Son la integración más simple, sin necesidad de un SDK de cliente especializado ni infraestructura.

### ¿Cuándo son los WebSockets la mejor opción?

Los WebSockets son mejores para streaming de datos continuo y en tiempo real hacia clientes de navegador, como tickers de precios en vivo, actualizaciones de order book o dashboards. Ofrecen soporte nativo de navegador y bajo overhead por mensaje (2-6 bytes) después del handshake inicial.

### ¿Qué problemas está diseñado para resolver gRPC?

gRPC está optimizado para servicios de backend que mueven datos estructurados a tasas altas, como pipelines de indexers o streaming de datos de validadores. Provee serialización binaria, streams multiplexados, contratos tipados mediante Protocol Buffers, backpressure integrado y propagación de deadlines.

### ¿Puedo usar webhooks, WebSockets y gRPC juntos en el mismo sistema?

Sí, muchos sistemas en producción combinan los tres: gRPC para comunicación de servicio a servicio en el backend, WebSockets para actualizaciones en tiempo real en el navegador, y webhooks para notificar a sistemas externos sobre eventos discretos. Cada protocolo resuelve una capa arquitectónica distinta.

### ¿Cuáles son las diferencias de rendimiento entre estos protocolos?

gRPC entrega la latencia más baja y el throughput más alto mediante codificación binaria y multiplexación de HTTP/2; los WebSockets ofrecen bajo overhead (2-6 bytes por mensaje) para streaming en navegador; los webhooks tienen el mayor costo por mensaje debido al overhead completo del round-trip HTTP, pero priorizan la simplicidad sobre el rendimiento.

### ¿Cuáles son las principales desventajas de cada protocolo?

Los webhooks tienen problemas con eventos de alta frecuencia y tráfico en ráfaga; los WebSockets enfrentan desafíos de escalamiento con churn de conexiones y tormentas de reconexión tipo thundering-herd; gRPC requiere configuración del toolchain de protobuf, carece de soporte nativo de navegador, y necesita un proxy (gRPC-Web) para clientes web.

### ¿Cómo soporta Alchemy estos protocolos para aplicaciones de blockchain?

Alchemy provee Custom Webhooks para notificaciones de eventos en más de 100 chains, Smart WebSockets para streams filtrados de eth_subscribe con reconexión automática, y streaming Yellowstone gRPC en Solana que entrega actualizaciones de cuentas con latencia de menos de 10 ms directamente desde la memoria del validador.