O sistema de notificação criado tem com intuito de ser uma abstração de envio central para todos os times que desejem enviar algum tipo de notificação.
Para a utilização basica basta executar um docker-compose up -d
e as configurações
serão criadas automaticamente.
- Inicialmente será suportado apenas o envio de notificações para uma aplicação web. Suporte a novos tipos de notificações, tais como Push, SMS e email, serão incluídos no futuro;
- Deverá ser permitido o agendamento para o envio das notificações;
- Usuários que solicitaram o opt-out não deverão mais receber notificações;
- As notificações devem ser entregues o mais rápido possível, porém pequenos delays são aceitáveis;
- A solução deve ser escalável e resiliente;
A implementação gira em torno de três endpoints
notification/web/send
notification/web/schedule
notification/customer/config
No endpoint notification/web/send
se envia uma notificação de forma automatica o usuário
através de alguma interface de comunicação de fila, para que o serviço não sofra muito no tempo
espera de uma cominicação sincrona
- O objeto
customer
identifica qual usuário vai receber a notificação e contem o identificador unico para que seja entregue na central de notificação - O
title
identifica o titulo que vai ser colocado na caixa da notificação. - A lista
contents
é composta por um hypertext que pode ser utilizado como um "molde" para a interface de notificação o pensamento é que seja implementado uma biblioteca que que extraia essas informações e seja utilizada como modelo para todos os outros serviçs que desejam. - O campo
redirectUrl
é o campo que redireciona a notificação quando clicada e busca as informaçoes - adicionais da notificação.
{
"customer": {
"id": 1
},
"title": "Awesome notification",
"contents": [],
"redirectUrl": "url"
}
- O objeto
customer
identifica qual usuário vai receber a notificação - O
status
da notificação que pode serSENT | DISABLED
O envio de notificação pode ser agendado pelo endpoint notification/web/schedule
Consiste em algumas informações importantes
- O objeto
customer
identifica qual usuário vai receber a notificação e contem o identificador unico para que seja entregue na central de notificação - O
title
identifica o titulo que vai ser colocado na caixa da notificação. - A lista
contents
é composta por um hypertext que pode ser utilizado como um "molde" para a interface de notificação o pensamento é que seja implementado uma biblioteca que que extraia essas informações e seja utilizada como modelo para todos os outros serviçs que desejam. - O campo
redirectUrl
é o campo que redireciona a notificação quando clicada e busca as informaçoes adicionais da notificação. - O campo
schedule
fala o momento em que se deve enviar a notificação para o usuários.
{
"customer": {
"id": 1
},
"title": "Awesome notification",
"contents": [],
"redirectUrl": "url",
"schedule": "yyyy-MM-dd hh-mm-ss"
}
- O objeto
customer
identifica qual usuário vai receber a notificação - O
status
da notificação que pode serSCHEDULED | DISABLED
A central de notificação inicial faz o controle dos usuários que querem desabilitar ou habilitar as notificações
gerais apenas pelo endpoint notification/customer/config
- O objeto
customer
identifica qual usuário vai receber a notificação e contem o identificador unico para que seja entregue na central de notificação - O campo
notify
é a flag se ele deve ser notificado ou não.
{
"customer": {
"id": 1
},
"notify": false
}
A arquitetura consiste em duas partes:
- Uma parte sincrona que recebe os dados para serem enviados para os usuários através dos endpoints sincronos.
- A parte assincrona que contém os
workers
que processam as notificações de forma assincrona e entregam com a maior velocidade possivel.- A sugestão de comunicação entre a parte sincrona e assincrona dever ser feita por um mecanismo FIFO para garantir a prioridade da entrega de forma sequencial
- Temos um worker especial no desenho que é
schedule worker
que funciona com uma busca no banco em um intervalo de tempo especificado para o envio da notificação naquele intervalo de tempo. - Outro ponto importante é todos os workers devem ser implementados em formato de containers para serem o mais isolados possiveis, sendo possivel o shutdown dos mesmos de forma isolada que não impacte o serviço por um todo.
- Outra questão é, dependendo do nivel do sistema pode ser mais interessante se utilizar um provedor de notificação como a salesforce ou até mesmo um onesignal que já tem abstrações de notificação agendadas de forma mais robusta.
- A comunicação entre a notificação e o provedor web em um momento mais simples pode ser implementado um websocket para que seja comunicado novas notificações, e no click do botão de notificação ele carregue todas as notificações armazenadas para determinado usuário, de forma paginada, ou até mesmo uma busca mais avançada apenas com os identificadores dessa notificação
Os banco de dados escolhidos foram mongodb
e postgres
em que como o formato da notificação é mutável e tem um formato
de documento é melhor o armazenamento em mongodb. Já o armazenamento na central de notificações foi pensando em um banco
relacional para se mantar o relacionamento de customerId
global do usuário, aquilo que o define na organização e as
suas configurações;
###Feature Implementation
A implementação da funcionalidade segue o diagrama Implementação da feature onde mostra a conexão necessária entre os modulos.
- O uso de spring para os workers (como foi pensando inicialmente) pode gerar daemons muito gigantes fazendo com que os clusteres sejam muito pesados.
- Testes de integração entre os clientes e o serviço
- Implementação da lib de comunicação