ESTE É UM CONTEÚDO EM DESENVOLVIMENTO E NÃO DEVE SER CONSIDERADO COMO VERSÃO FINAL!
Clique aqui para maiores informações

Ir para o final dos metadados
Ir para o início dos metadados

You are viewing an old version of this content. View the current version.

Comparar com o atual View Version History

« Anterior Versão 4 Próxima »

Requisitos não funcionais

Avaliar melhor alternativa para incluir recomendações à instituição transmissora em caso de incapacidade do cluster receber o evento a ser encaminhado ao ecossistema   

Exemplos: throughput do cluster; indisponibilidade do cluster 

Configurações Padrão e aceleradores 

Sugestão de configuração de permissionamento, controle de acesso, configuração de tópicos   

Schema de dados  

Exemplo de receptor  

Kafka connect  

Kafka Client SDK  

Exemplo do Kafka cluster  

Serviço (AWS MSK, Confluent, Strimzi, GCP GCMS, Azure Event Hub, Red Panda, etc)  

Open Source (Apache Kafka)  

Os artefatos serão desenvolvidos pela DTO ou fornecedor e disponibilizados aos participantes em ambiente 

Premissas Operacionais 

Disponibilidade  

Escalabilidade do consumidor – número mínimo de partições de 2  

Fator de replicação – mínimo 3 na criação de todos os tópicos  

Armazenamento (persistência de 1 semana em mensagens)  

Throughput (mensagem por segundo) – visão receptora  

Monitoramento e alertas  

A nuvem da mensageria estará limitada à região geográfica BR  

Exigência de baixa latência por parte da tecnologia demanda atenção e pode não funcionar corretamente nos casos em que consumidores e provedores estejam fora na mesma região geográfica (incluir na planilha de setup a declaração de região geográfica para consumidor e provedor) 

Cenários de teste 

Medidas para ter os critérios do sucesso:

  • Eficiência x custo operacional do uso de Compact  

  • Simulação de downtime do consumidor – implicações  

  • Simulação de downtime do transmissor – implicações  

  • Simulação de grande volume em curto período (mediante retenção de mensagens no produtor) – a depender do voluntário 

Anotações

Nice to have: Baselines devem ser orientados à quantidade de consentimentos (e contas) relacionadas  

Dessa forma, IFs diferentes terão bases diferentes   

Especialistas nos ajudam a determiná-los e calibrá-los durante a PoC  

As métricas de eficiência devem levar em consideração se o produtor das mensagens possuía, durante a PoC, restrições com relação ao escopo dos tipos de eventos que geram mudança de saldo  

Detalhar melhor os requisitos de negócio – durante o detalhamento das mensagens incluir header explicativo dos eventos geradores. OBS: se atentar a características de débito em lote  

Para requisitos de negócio, se não tiver um número aceitável de voluntárias, a estratégia pode ser revista  

[Configurações padrão] Entender como a latência vai afetar os eventos 

  • Sem rótulos