---
title: "Geyser gRPC - Mejores prácticas"
description: "Consejos esenciales para clientes de Geyser gRPC listos para producción, como ping/pong, reconexión y filtros. Solana Stream SDK es compatible con Geyser gRPC."
canonical: "https://erpc.global/es/doc/geyser-grpc/best-practices/"
locale: "es"
---

# Geyser gRPC - Mejores prácticas

Esta guía cubre los patrones esenciales para crear aplicaciones robustas y listas para producción con Geyser gRPC. Solana Stream SDK es compatible con Geyser gRPC.

## Primeros pasos

- Empieza por lo sencillo: comienza con suscripciones de slots para familiarizarte con el streaming antes de añadir filtros complejos.  
- Usa los filtros con criterio: suscríbete solo a lo que necesitas para reducir el ancho de banda y la CPU.

```rust
SubscribeRequestFilterTransactions {
    vote: Some(false),   // Exclude vote txs
    failed: Some(false), // Exclude failed txs
    ..Default::default()
}
```

## Gestión de la conexión

- Reconexión automática: cuenta con que habrá problemas de red; reconecta con backoff exponencial.  
- Gestión de ping/pong: los servidores de Yellowstone gRPC envían ping. Responde siempre con pong o el servidor puede cerrar la conexión (una causa habitual de desconexiones a los ~30 s).  

```rust
if matches!(update.update_oneof, Some(UpdateOneof::Ping(_))) {
    subscribe_tx.send(SubscribeRequest {
        ping: Some(SubscribeRequestPing { id: 1 }),
        ..Default::default()
    }).await?;
}
```

- Recuperación de huecos: usa `from_slot` después de reconectar para evitar pérdidas de datos (los duplicados son aceptables).

```rust
subscribe_request.from_slot = if tracked_slot > 0 {
    Some(tracked_slot) // Optionally subtract a small buffer to dodge reorgs
} else {
    None
};
```

## Patrones de arquitectura

- Separa la recepción y el procesamiento con canales para desacoplar la E/S de red de la lógica de negocio y añadir backpressure.

```rust
let (tx, rx) = mpsc::channel::<SubscribeUpdate>(10_000);
// ingress task reads stream and tx.send(...)
// processing task consumes rx and does business logic
```

- Usa canales acotados: elige la capacidad según la velocidad de procesamiento y la tolerancia a la pérdida de datos (menor = menos memoria y más descartes; mayor = más memoria y menos descartes).

## Rendimiento y resiliencia

- Supervisa la latencia de procesamiento y registra cuándo se superan los umbrales.  
- Agrupa las escrituras en la base de datos; vuélcalas al alcanzar un tamaño de lote o un intervalo.  
- Usa E/S asíncrona para las llamadas externas; delega el cómputo pesado a tareas o hilos de trabajo.  
- Reutiliza las solicitudes de suscripción para reducir las asignaciones de memoria.

## Gestión de errores

- Distingue los tipos de error (stream, procesamiento o canal).  
- Corrige una solicitud inválida antes de reintentarla; usa backoff exponencial consciente de la pausa solo cuando una respuesta indique que se puede reintentar.
- Registra o mide las actualizaciones descartadas para detectar situaciones de consumidor lento.

## Corrige antes de reintentar y usa backoff consciente de la pausa

Conserva el primer error gRPC antes de que un bucle de reconexión lo sustituya. Registra su estado y mensaje, además de los metadatos presentes `x-erpc-error-code`, `x-erpc-error-reason`, `x-erpc-doc-url`, `x-erpc-retry-after-seconds` y `x-erpc-retry-at`. Un cierre temprano puede parecer un error de transporte genérico, por lo que quizá no incluya todos los trailers.

Corrige una solicitud inválida, una forma de filtro rechazada o una discrepancia de registro de IP antes de reintentar. En una pausa de ERPC, espera el plazo devuelto; es más específico que el backoff local. Usa backoff exponencial acotado para fallos de disponibilidad y otras respuestas reintentables. No repitas una solicitud sin cambios solo porque devolvió un estado distinto de cero.

## Uso de recursos y capacidad de procesamiento

Las protecciones Shared impiden que una carga consuma la capacidad de entrega necesaria para otros clientes de ERPC. Un stream puede hacerse lento por el ancho de banda efectivo, CPU, memoria, la cola del consumidor, escrituras en base de datos o llamadas externas. Los recursos suficientes deben corresponder a la carga; un receptor lento no identifica por sí solo qué parte está limitada.

Mide la tasa de datos máxima en el consumidor. Convierte MB/s a Mbps con `MB/s × 8` y deja margen sobre el pico medido. No hay un mínimo fijo sin medir. Mantén breve el trabajo de recepción, entrega las actualizaciones a una cola acotada y escala o reduce la suscripción si el procesamiento no puede seguir el ritmo. Una cola acotada limita el uso de memoria; no resuelve un consumidor sostenidamente lento.

## Gestión de datos

- Gestiona los duplicados al usar `from_slot` (caché con límite de tiempo o restricciones en la base de datos).  
- Elige el commitment según el caso de uso:  
  - processed: dashboards más rápidos; puede revertirse  
  - confirmed: buen valor predeterminado para la mayoría de las aplicaciones e indexadores  
  - finalized: cuando se requiere certeza absoluta

## Suscripciones dinámicas

Usa el stream bidireccional para actualizar las suscripciones en tiempo de ejecución (cambiar filtros en caliente, ampliar la cobertura) sin reconectar.

## Lista de verificación para producción

- ✅ Reconexión automática con backoff exponencial  
- ✅ Recuperación de huecos con `from_slot`  
- ✅ Gestión de ping/pong (evita las desconexiones a los 30 s)  
- ✅ Recepción y procesamiento separados con canales acotados/backpressure  
- ✅ Registro de errores y métricas/alertas  
- ✅ Seguimiento de la latencia de procesamiento  
- ✅ Gestión de duplicados y optimización de filtros  
- ✅ Escrituras por lotes (si se persisten datos)  
- ✅ Apagado ordenado y health checks

## Recursos adicionales

- Solana Stream SDK (compatible con Geyser gRPC): https://github.com/ValidatorsDAO/solana-stream