Objetivo:

Projete a arquitetura do sistema de nível empresarial para oferecer suporte a e-mail, SMS, bate-papo e outras integrações de aplicativos sociais públicos usando API:

  • Email
  • SMS/OTP
  • Notificações por push (navegador móvel e da Web)
  • Chat – Whatsapp/Telegram

É um recurso genérico de todos os tipos de aplicativos web e móveis, que é necessário para todos os aplicativos distribuídos modernos, independentemente do uso de quaisquer linguagens de programação e tecnologias. Você pode personalizar com base em seus casos de uso de negócios.

Tentei simplificar este conceito de design para atender aos requisitos comuns de casos de uso com alta disponibilidade, alta perfromance e serviços analíticos. É um meio de comunicação muito importante com os clientes/usuários através de seus dispositivos desktop/móveis. Eu recomendaria implementar usando arquitetura de microsserviço e implantar contêineres Kubernetes para torná-lo totalmente nativo da nuvem sistema moderno. Vamos começar!

Requisito Funcional:

  • Enviar notificações
  • Priorizar notificações
  • Enviar notificações com base nas preferências salvas do cliente
  • Mensagens de notificação únicas/simples e em massa
  • Casos de uso do Google Analytics para várias notificações
  • Comunicação de mensagens de notificação

Requisitos não funcionais (NFR):

  • Alto perfromance
  • Altamente disponível (HA)
  • Baixa latência
  • Design extensível/conectável para adicionar mais clientes, adaptadores e fornecedores.
  • Suporte Android / iOS móvel e desktop / laptop navegadores web.
  • Integração de API com todos os módulos de notificação e integrações externas com clientes e prestadores de serviços/fornecedores.
  • Escalável para maior carga no local (VMware Tanzu) e em serviços de nuvem pública como AWS, GCP ou Azure, etc.

Arquitetura de Projeto de Sistemas:

Nota: Por favor, clique na imagem para ver a visão clara!

Estas são as considerações e os componentes do design da solução:

1. Clientes de notificação:

Esses clientes solicitarão mensagens únicas e em massa usando chamadas de API. Esses clientes enviarão mensagens de notificação para serviços de notificação simples e em massa:

  • Clientes de notificação em massa: esses clientes enviam notificações em massa.
  • Clientes de notificação simples: esses clientes enviam notificações únicas.

2. Serviços de notificação:

Esses serviços são serviços de entrada que irão expor APIs REST aos clientes e interagir com os clientes. Eles são responsáveis por criar mensagens de notificação consumindo o Serviço de Modelo. Essas mensagens também serão validadas usando o Serviço de Validação.

  • Serviço de notificação simples: Esse serviço exporá APIs para integrar o cliente com serviços de back-end. É um serviço principal, que lidará com uma solicitação de notificação simples.
  • Serviço de notificação em massa: Esse serviço exporá APIs para integrar o cliente com serviços de back-end. É um serviço principal, que lidará com a solicitação de notificação em massa.

Esse serviço também gerenciará mensagens de notificação. Ele persistirá as mensagens enviadas para bancos de dados e manterá o log de atividades. A mesma mensagem pode ser reenviada usando APIs desses serviços. Ele fornecerá APIs para adicionar/atualizar/excluir e exibir mensagens antigas e novas. Ele também fornecerá painel da web que deve ter opção de filtro para filtrar mensagens com base em diferentes critérios, como intervalo de datas, prioridade, usuário do módulo, grupos de usuários, etc.

3. Serviço de Modelo:

Este serviço gerencia todos os modelos prontos para usar para OTP, SMS, e-mail, bate-papo e outras mensagens de notificação push. Ele também fornece APIs REST para criar, atualizar, excluir e gerenciar modelos. Ele também fornecerá uma página de painel de interface do usuário para verificar e gerenciar modelos de mensagem do console da Web.

4. Serviço de Seleção de Usuários:

Este serviço fornecerá serviços para escolher os usuários-alvo e vários módulos de aplicação. Pode haver casos de uso para enviar mensagens em massa para um grupo específico de usuários ou módulos de aplicativos diferentes. Pode ser também AD/IAM/eDirectory/banco de dados de usuários/grupos de usuários com base nas preferências do cliente. Internamente, ele consumirá serviços de API de APIs de Serviço de Perfil de Usuário e verificará as preferências de notificação dos clientes.

5. Serviço de Perfil de Usuário:

Este serviço fornecerá vários recursos, incluindo o gerenciamento do perfil dos usuários e suas preferências. Ele também fornecerá recurso para cancelar a assinatura de notificações e também frequência de recebimento de notificações, etc. O Serviço de Notificação dependerá deste serviço.

6. Serviço Comum de Notificação

  • Serviço de Agendamento:

Esse serviço fornecerá APIs para agendar notificações imediatas ou a qualquer momento. Pode ser qualquer um destes seguintes:

  • Segundo
  • Minuto
  • Horário
  • Diário
  • Semanalmente
  • Mensal
  • Anual
  • Frequência personalizada etc.

Pode haver outros serviços também, que podem ser mensagens acionadas automaticamente com base nos horários agendados.

  • Serviço de validação:

Este serviço é o único responsável por validar as mensagens de notificação em relação às regras de negócios e ao formato esperado. As mensagens em massa devem ser aprovadas apenas pelo administrador autorizado do sistema.

  • Serviço de validação:

Também priorizará a notificação com base em prioridades altas, médias e baixas. As mensagens de notificação OTP têm prioridade mais alta com um tempo de expiração limitado, elas sempre serão enviadas em prioridade mais alta. O Manipulador de Saída Comum consumirá mensagens e processará e enviará com base nas mesmas prioridades da leitura em três filas diferentes alta, média e baixa. Outro caso de uso de mensagens em massa pode ser enviado usando baixa prioridade durante o horário de folga. As notificações do aplicativo durante as transações podem ser enviadas para prioridade média, como e-mail, etc. As empresas decidirão a prioridade com base na criticidade das notificações.

7. Filas de prioridade de eventos (Hub de eventos):

Ele fornecerá serviço de hub de eventos que consumirá mensagens de serviços de notificação em tópicos altos, médios e baixos. Ele envia mensagens processadas e validadas para o Serviço de Manipulador de Notificações, que usa internamente o Serviço de Preferências de Notificação para verificar as preferências pessoais dos usuários.

Ele terá estes três tópicos, que serão usados para consumir/enviar mensagens com base na prioridade do negócio:

  • Alto
  • Média
  • Baixo

8. Manipulador de saída comum:

Esse serviço consumirá mensagens de notificação do Hub de Eventos pesquisando filas de prioridade de eventos com base em sua prioridade. Alta precedência será dada à fila “Alta” e assim por diante. Finalmente, ele enviará mensagens de notificação para o adaptador específico de mensagens através do Hub de Eventos.

Esse serviço também buscará usuários/aplicativos de destino no Serviço de Seleção de Usuários.

9. BD de notificação

Ele irá persistir todas as mensagens de notificação com seu tempo de entrega, status etc. Ele terá um cluster de bancos de dados com um líder que será usado para executar todas as operações de gravação e leitura será em réplica de leitura / seguidores. Deve ser um banco de dados No-SQL.

10. Hub de eventos de saída:

Ele finalmente transmite mensagem para vários adaptadores suportados. Esses adaptadores serão baseados em diferentes dispositivos (desktop/mobile) e tipos de notificação (sms/OTP/Email/Chat/Push notifications).

11. Adaptadores de notificação:

Estes são adaptadores que irão transformar as mensagens recebidas do hub de eventos (Kafka) e enviar para fornecedores externos de acordo com seu formato suportado. Estes são alguns adaptadores, podemos adicionar mais com base nos requisitos de caso de uso:

  • Serviço de adaptador OTP
  • Serviço de adaptador SMS
  • Serviço de adaptador de e-mail
  • Serviço de adaptador de notificação no aplicativo
  • Serviço de adaptador de notificação de bate-papo do WhatsApp
  • Serviço de adaptador de notificação do Telegram

12. Notificação de Fornecedores:

Esses são os fornecedores externos de SAAS (na nuvem/on-prem), que fornecem transmissão de notificação real usando sua infraestrutura e tecnologias. Eles talvez pagaram serviços corporativos como AWS SNS, MailChimp etc.

  • Serviço de integração de fornecedores de SMS
  • Serviço de integração de fornecedor de e-mail
  • Serviço de Integração do Fornecedor de Notificação por Push de Aplicativo
  • Serviço de integração de fornecedores do WhatsApp
  • Serviço de integração de fornecedores do Telegram

13. Serviço Analítico de Notificação

Este serviço fará todas as análises e identificará o uso de notificações, tendências e fará um relatório em cima disso. Ele extrairá todas as mensagens de notificações finais do banco de dados analítico (Cassandra) e dos bancos de dados de notificação para fins de análise e relatório.

Estes são alguns casos de uso:

  • Número total de notificações por dia/por segundo.
  • Que é um sistema de notificação muito utilizado.
  • Qual é o tamanho médio e a frequência das mensagens.
  • Filtre mensagens com base em suas prioridades e muito mais…

###
14. Rastreador de Notificações

Esse serviço lerá continuamente as filas do Hub de eventos e rastreará todas as notificações enviadas. Ele captura metadados das notificações, como tempo de transmissão, status de entrega, canal de comunicação, tipo de mensagem, etc.

15. Cluster de banco de dados Cassandra

Esse cluster de banco de dados persistirá todas as notificações para fins de análise e geração de relatórios. Baseia-se em escrever mais e ler menos conceito.

Isso fornecerá bom desempenho e baixa latência para um alto número de notificações, porque gerencia internamente um alto número de operações de gravação e sincroniza com outros nós de banco de dados e mantém dados/mensagens duplicados para alta disponibilidade e confiabilidade. As mensagens estarão sempre disponíveis no caso de algum nó falhar.

Por favor, compartilhe comentários e deixe-me saber se você tem alguma sugestão para tornar este design melhor!

15. Serviço de Notificação de Entrada

Esse serviço exporá o ponto de extremidade da API a clientes e aplicativos externos para enviar mensagens de entrada.

16. Hub de eventos de entrada

Este tópico será usado para enfileirar e processar todas as mensagens de notificação de entrada de clientes de notificação de entrada.

17. Manipulador de entrada

Isso consumirá todas as mensagens de notificação recebidas do tópico INBOUND.

18. Clientes de Notificação de Entrada

Essas mensagens de notificação de entrada virão de fontes/aplicativos internos e externos.

Artigo Original