Uma aplicação recebe uma solicitação para gerar um arquivo. A pessoa que fez o pedido precisa acompanhar o andamento, enquanto um processo de backend prepara o resultado. À primeira vista, tudo parece fazer parte de um único fluxo. Tecnicamente, porém, existem responsabilidades distintas: executar o trabalho e comunicar o que está acontecendo.
Uma fila de trabalho ajuda a separar a criação da demanda de seu processamento. A aplicação publica uma tarefa; um consumidor assume essa tarefa, executa a atividade e confirma a conclusão. O Skama ocupa esse papel no ecossistema Era Logic, com persistência e controle do ciclo entre publicação, concessão de execução e confirmação.
A confirmação importa porque receber uma tarefa não é a mesma coisa que terminá-la. Um processo pode parar durante a execução. Uma conexão pode ser interrompida depois de um efeito externo acontecer, mas antes de a fila receber a confirmação. A arquitetura precisa considerar essas situações para saber como tratar uma nova tentativa.
É nesse ponto que a idempotência entra no projeto. Se o consumidor executar novamente uma mesma operação, a aplicação precisa impedir efeitos indesejados, como registrar duas vezes um resultado que deveria ser único. O controle da fila ajuda a organizar as tentativas; as regras do negócio continuam responsáveis pelos efeitos que acontecem fora dela.
Já a comunicação em tempo real atende a outra necessidade. Uma interface pode precisar saber que o arquivo está em preparação ou que já está disponível. Nesse caso, o interesse é distribuir a atualização aos participantes conectados. O Lig utiliza publicação e assinatura em canais para compor esse caminho entre produtores de mensagens e assinantes.
Quem publica uma mensagem em um canal não precisa conhecer individualmente cada interface interessada. Os participantes se inscrevem no contexto que precisam acompanhar. Isso ajuda a organizar a comunicação de status, painéis e experiências conectadas. A aplicação ainda precisa definir quais canais cada pessoa pode acessar e como recuperar seu estado depois de uma desconexão.
As duas tecnologias podem participar do mesmo desenho. Em um exemplo conceitual, a aplicação registra a solicitação, um consumidor processa a tarefa pela fila e uma atualização avisa a interface sobre a mudança de estado. Esse desenho não é uma integração automática entre os produtos: ele ilustra como responsabilidades diferentes podem se complementar.
A escolha começa pelo comportamento esperado. Se o objetivo é acompanhar mudanças com participantes conectados, pense no fluxo de realtime. Se há trabalho a executar e confirmar, examine o processamento em fila. Quando existem as duas necessidades, mantenha cada responsabilidade explícita. Isso torna a arquitetura mais fácil de compreender, testar e operar.