> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # O que é o Streaming Hub? > O Streaming Hub é a borda de entrega gerenciada da Lerian. Ele consome o stream interno de eventos da plataforma e distribui os eventos para consumidores de webhook, de fila e de pull. **Streaming Hub** é o serviço de entrega de eventos da Lerian. Ele fica na borda entre o stream interno de eventos da plataforma e os sistemas que você roda fora dela. Ele entrega cada evento que interessa a você para um destino seu: um webhook, uma fila na nuvem ou um cursor do qual você faz pull. Os produtos Lerian publicam eventos de domínio (fatos de negócio no passado, como uma conta criada ou uma transação lançada) em um backbone de streaming compartilhado. O Streaming Hub se inscreve nesse backbone em seu nome, compara os eventos com as subscriptions que você registra e os entrega. Você descreve *quais eventos vão para onde*. O hub é dono do ciclo de consumir, comparar e entregar. ## O Streaming Hub na plataforma Lerian *** O backbone de eventos da plataforma é um [stream baseado em CloudEvents](/pt/reference/events/overview) compartilhado, transportado em Kafka/Redpanda e produzido pela biblioteca `lib-streaming` da Lerian. A entrega nesse stream é **pelo menos uma vez**, e eventos de cada produto e tenant trafegam nos mesmos tópicos. Para consumi-lo diretamente, você deve rodar seu próprio consumidor Kafka. Esse consumidor controla offsets, filtra tipos de evento, deduplica, refaz entregas que falharam e assina requisições de saída. O Streaming Hub faz esse trabalho uma vez, como uma borda gerenciada. Ele **consome** o stream interno e nunca produz nele. Ele transforma um feed bruto de eventos em entrega por destino que você configura por uma única API. Você registra uma subscription, o hub acompanha o stream e os eventos correspondentes chegam ao seu endpoint já assinados e correlacionados. Como o hub é a borda de entrega, as garantias sobre as quais você constrói são o contrato de entrega do hub, não o stream bruto. Seu endpoint de webhook verifica uma assinatura, deduplica por um id de evento estável e responde rápido. Veja [Como o Streaming Hub funciona](/pt/platform/streaming-hub/how-streaming-hub-works) para o caminho completo que um evento percorre. ## Tipos de sink *** Uma subscription entrega para exatamente um destino, chamado de **sink**. O Streaming Hub aceita cinco tipos de sink: | Tipo de sink | Entrega | Destino | | ------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------- | | `webhook` | Push | Um endpoint `https://` seu. Cada requisição é assinada com HMAC e carrega headers de correlação CloudEvents. | | `pull` | Pull | Um cursor no servidor. Seu consumidor lê uma página de eventos com `GET /v1/events`; a leitura também serve como confirmação. | | `sqs` | Push | Uma fila Amazon SQS, acessada por uma credencial de saída verificada ou por um grant delegado da AWS. | | `rabbitmq` | Push | Um exchange e uma routing key do RabbitMQ. | | `eventbridge` | Push | Um event bus do Amazon EventBridge, acessado por uma credencial de saída verificada ou por um grant delegado da AWS. | Sinks push (`webhook`, `sqs`, `rabbitmq`, `eventbridge`) entregam eventos para você à medida que eles correspondem. O sink `pull` inverte isso: o hub mantém os eventos em um cursor e seu consumidor os busca no próprio ritmo. Uma subscription de webhook fica apta a receber entregas depois que uma sondagem assinada confirma que seu endpoint responde. Subscriptions de RabbitMQ exigem uma credencial de broker que o hub sonda antes da ativação. SQS e EventBridge podem ser ativados com uma credencial de saída que o hub sonda, ou com um grant delegado da AWS que não armazena credencial. Veja [Gerenciar subscriptions](/pt/platform/streaming-hub/managing-subscriptions). ## Modelo de deploy *** O Streaming Hub roda **BYOC** por padrão: você faz o deploy dele na sua própria infraestrutura como um serviço single-tenant, com um tenant de control plane configurado e sem dependência da gestão de tenants hospedada pela Lerian. Essa é a forma que a maioria dos clientes roda. Um modo **SaaS multi-tenant** fica atrás de uma flag de configuração. Quando habilitado, o hub atende muitos tenants pelo bus compartilhado e roda um consumidor Kafka de aplicação por réplica capaz de ingestão, com credenciais de broker no nível do deploy. O Tenant Manager fornece a lista de tenants ativos usada para autorizar o control plane. Um listener de ciclo de vida no Redis e uma atualização periódica mantêm essa lista em dia. A lista não cria um consumidor por tenant nem funciona como um gate de descarte na ingestão. O Secrets Manager continua sendo a fonte de credenciais para a descoberta autenticada de manifestos de produtor, não para a conexão Kafka. Subscriptions, eventos e cursores continuam isolados por tenant id. O caminho BYOC não carrega nada desse maquinário. Veja o [modelo de multi-tenancy](/pt/platform/multi-tenancy) de toda a plataforma para ver como o isolamento por tenant funciona nos produtos Lerian, e [Operar o Streaming Hub](/pt/platform/streaming-hub/operating-streaming-hub) para os detalhes de deploy. ## A API de control plane *** Você gerencia subscriptions pela API de control plane `/v1`. Cada rota é autenticada com um JWT do plugin-auth (`Authorization: Bearer `). O tenant sempre vem das claims do token validado, nunca de um corpo de requisição, caminho ou query. Por ela, você: * cria, lista, lê e exclui subscriptions. * verifica um destino (`ping` / `verify`) e fornece credenciais de fila. * rotaciona um segredo de assinatura de webhook. * lê a saúde de entrega de uma subscription. * faz pull de eventos (`GET /v1/events`) para sinks `pull`. * navega pelo [catálogo](/pt/reference/events/overview) de eventos que o hub enxerga. O conjunto completo de operações, os formatos de requisição e os tokens de erro estão na referência da API. Comece pela [introdução da referência](/pt/reference/introduction). ## Próximos passos *** O caminho que um evento percorre: ingestão, correspondência, despacho, nova tentativa e desativação automática. Crie subscriptions de webhook e de fila, conecte grants da AWS e rotacione segredos. Verifique assinaturas de webhook, deduplique entregas e faça pull de eventos. O contrato CloudEvents compartilhado que cada evento Lerian segue.