Forem: Guilherme Marcial

Construindo um serviço de log distribuido: Write-Ahead log

Guilherme Marcial — Mon, 12 Jun 2023 06:21:26 +0000

Introdução

Sistemas distribuídos é um dos temas do qual tenho muito interesse, para começar uma trilha de estudos sobre, resolvi começar com uma abordagem prática, construindo algo real que proporcione uma visão geral e seja próximo da minha atual realidade, optei pelo livro Distributed Services with Go: Your Guide to Reliable, Scalable, and Maintainable Systems do Travis Jeffery, onde a proposta do livro é entender sistemas distribuídos ao construir um

Essa série faz parte do estudo prático sobre a jornada de construção do serviço de log distribuído proposto no livro, onde consiste em armazenar, compartilhar e processar dados ordenadamente, operações atômicas usando log.

Seguindo um caminho parecido do qual Travis Jeffery fez ao construir o jocko, uma implementação do Kafka em Go.

Repositório do projeto: gmarcial/gproglog

Logs

A ideia da construção do serviço é entender os conceitos essenciais por trás do sistemas distribuídos, como os logs.

Começaremos pelo core do serviço, o write-ahead log, solução utilizada em sistemas distribuídos para atomicidade e durabilidade, replicação/distribuição dos dados, backup, recuperação de falha, consenso e mais.

Alguns exemplos de sistemas que usam: Bancos de dados, filas, algoritmos de consenso como paxos e raft, storage engine, change data capture (cdc) e data-stream.

O Write-Ahead Log é uma abstração de armazenamento append-only de registros em sequência, ordenada pela ordem da ocorrência dos registros e cada registro recebe um identificador único e sequencial, indexando o registro a partir do deslocamento no momento que o registro ocorreu.

Novos registros são adicionados ao final e a leitura ocorre no início do log, seguindo a sequência e ordem que os registros aconteceram, do mais antigo para o mais novo.

Para uma explicação profunda e detalhada sobre o conceito, sugiro a leitura do artigo The Log: What every software engineer should know about real-time data's unifying abstraction do Jay Kreps, um dos criadores do Kafka, precursor de muito do que temos hoje de event-stream, stream processing e real-time a partir das experiências da engenharia do Linkedin.

No artigo ele aborda não somente o conceito, mas que os logs são o coração dos sistemas distribuídos, uso, integração, real-time stream processing, surgimento do kafka e como esse conceito está presente no nosso dia a dia, sendo o kafka um log como serviço utilizado amplamente.

Outro artigo que recomendo, muito interessante e que é correlacionado, é o Stream processing, Event sourcing, Reactive, CEP… and making sense of it all do Martin Kleppmann.

Solução

O serviço será cliente do Log para gerenciamento dos registros.

A solução consiste em uma API para operar o log, essencialmente a escrita e leitura dos registros que são estruturados em segmentos.

Para a escrita de um novo registro o Log irá delegar para o Segment ativo, onde o processo envolve armazenar o registro através da Store e o indexar através do Index para posterior leitura.

Da mesma forma, para a leitura de um registro o Log irá delegar para o Segment ativo, onde o processo envolve encontrar o registro no Index e caso ele exista o recuperar na Store através do seu deslocamento.

Conforme o limite do Segment atual é atingido, um novo é criado e indicado como ativo.

Visão de como o log é estruturado, sendo representado de verde o Segment ativo:

Referência da implementação:

Próximos passos

Com a implementação do log os próximos passos na construção do serviço é prover e expor essas funcionalidades a na rede, para que possa operar.

Isso envolve vários passos até a distribuição e deploy propriamente dito no decorrer da série de estudos do livro.

Extras

Livro I Heart Logs: Event Data, Stream Processing, and Data Integration

Livro do Jay Kreps sobre logs, aparente evolução e continuação do seu post sobre logs, ainda não li, mas parece interessante.

Até o momento em que escrevo, é possível obter o livro gratuitamente através da Confluent nesse link, a alternativa é comprar.

Valencia: A Log-Structured On-Disk Hash

Valencia, implementação de um Log do Jay Kreps, muito parecida com a versão do Travis Jeffery.

Patterns of Distributed Systems por Unmesh Joshi

Unmesh Joshi tem um post no blog martinfowler sobre padrões de sistemas distribuídos, neles contém vários relacionados a log, onde vários são aplicados na solução do serviço do livro como:

Referências

Distributed Services with Go: Your Guide to Reliable, Scalable, and Maintainable Systems.

The Log: What every software engineer should know about real-time data's unifying abstraction.

Stream processing, Event sourcing, Reactive, CEP… and making sense of it all.

Patterns of Distributed Systems

Core Pay: System Design

Guilherme Marcial — Mon, 16 Aug 2021 21:59:29 +0000

Index

Introdução
O Problema
A Solução
- Expectativa de uso
- Atributos de qualidade
- Features
- Resumo
- Arquitetura e explicação detalhada
- Observabilidade
- Pontos de falha
- Evolutiva
Conclusão

Introdução

Este artigo é a abertura e explicação da solução inicial do projeto Core Pay 💰, uma iniciativa pessoal CoreLab 📦.

Um sistema central(core) para soluções financeiras(vulgo fintechs) comuns ou disruptivas, servindo como a interface principal para operações financeiras base 💰.

O Problema

Com o boom das fintechs, sempre tenho visto uma nova que não conhecia, indo des de negócios comuns e de contextos genéricos como contas digitais, e-wallets, pagamentos, plataformas de moeda eletrónica, crédito até disruptivos, aplicados em contextos e setores específicos como imobiliário, automobilístico, logística, beneficios, autopeças e por assim vai, mas no final todos têm em comum operações financeiras para realizar e dar vida a suas soluções.

Para cada uma dessas soluções é necessário o desenvolvimento dessa base, ao invés de apenas focar no desenvolvimento da solução principal, utilizando um sistema pronto para essa responsabilidade.

A Solução

Expectativa de uso

A ideia é que novas soluções financeiras genéricas ou disruptivas possam ter como alternativa utilizar um sistema open-source central para realizar as operações financeiras base, podendo assim focar no desenvolvimento das soluções específicas do negócio.

Pensado para que seja implantado internamente como a principal interface para operações financeiras, onde os demais sistemas integrariam com flexibilidade e configurabilidade ao mesmo para compor a solução como um todo.

Atuando principalmente como domínio financeiro das soluções.

Atributos de qualidade

Representam as capacidades necessárias identificadas que a arquitetura precisa ter para poder suportar e atender o produto concebido, tornando uma solução que atende ao negócio.

Para que isso aconteça, essas capacidades serviram de guia da concepção e evolução da arquitetura no seu alto a baixo nível, refletindo diretamente nas implementações e o que se espera das funcionalidades, para que esteja alinhada e continue alinhada como uma solução para o negócio.

O objetivo é deixar expresso e registrado as capacidades identificadas, resumidamente expressar o conceito e uma breve justificativa, que estará aprofundada, expressa detalhadamente no ciclo de desenvolvimento e medidas continuamente.

Base

Capacidades base para contribuir para a vida útil da aplicação, possibilitando ser continuamente funcional, mantida e evoluída, sem estar presa aos criadores, possibilitando também por novos contribuidores e mantenedores.

Readability
Testability
Evolvability
- Modifiability
- Modularity
- Simplicity

Negócio

Capacidades requisitadas para que o negócio possa ser suportado além do produto ser funcional, é preciso que além da entrega da funcionalidade, a aplicação opere essa funcionalidade conforme a demanda e dentro do contexto do negócio.

Auditability
Atomicity
Isolability
Consistency
Durability
Integrity
Security
Availability

Infraestrutura

Capacidades requisitadas para que a aplicação possa ser suportada, para conforme as necessidades a aplicação operar.

Observabiltity
Configurability
Fault Tolerance
Scalability
Performance

Mais detalhes na documentação do projeto.

Features

Algumas das features relacionas ao core business:

Transaction account

Check balance
Deposit
Withdraw
Pay
Transfer
Account statement and receipt
Open
Close
Block
Unlock

Lending/Loan

Overdraft
Active
Desactive
Adjust limit
Pay back

Credit

Active
Desactive
Check limit
Adjust limit
Adjust use limit
Pay
Instalment pay
Credit statement and receipt
Invoice
Pay Invoice

Ledger

Algumas das features relacionas a plataforma/infraestrutura:

Autenticação e autorização segregada para o provedor OIDC, atraves de uma interface configurável.
Aspectos arquiteturais de event-driven, onde os comportamentos do sistema produzem eventos, permitindo interfaces flexíveis para implementar e aplicar diferentes comportamentos necessários.
Possibilidade de integração com a API, optando entre interfaces REST, GRPC ou ambas.
Agnóstico aos sistemas integrados que compõem a arquitetura, acionados por portas e adaptadores, definindo interfaces que expressam bem o que se espera de possíveis implementações, permitindo a utilização de outras soluções ao invés do padrão.
Auditoria de todos os comportamentos do sistema.
Observabilidade em diferentes níveis e formas, configurável e flexível sobre interfaces bem definidas, possibilitando substituir as implementações padrão.
- Structured logging
- Monitoring
- Tracing
- Metrics
- APM
Escolher entre comunicação insegura ou segura autenticando apenas o servidor ou mútua, incluindo o cliente.
Flexível para compor e se encaixar em sua arquitetura como uma interface interna central de operações financeiras downstream, suportando suas soluções / produtos que possuem regras de negócios específicas, como e-wallets, bank, etc.
Uso da estratégia de "in-memory database" para operações financeiras.
Uso inicial de sharing como padrão para escalar horizontalmente o in-memory data, de forma configuravel.

Resumo

Ciclo do pedido da realização de uma operação financeira, foreground a nível do request:

1- Core Pay através de uma das interfaces da api, recebe uma requisição referente a um pedido de operação financeira, junto ao serviço de autorização, utiliza o access token para verificar se quem solicitou tem permissão para realizar essa operação.
2- Caso o solicitante seja autorizado, a partir desse pedido, é feito as validações que forem necessárias, aceitando o pedido caso esteja válido para ser processado, publicando em uma fila de pedidos a serem processados de forma assíncrona.
3- Responde que o pedido foi aceito.

Ciclo do processamento do pedido da realização de uma operação financeira, background:

4- É consumido da fila o pedido de operação financeira.
5- É feita novas validações se necessário.
6- Obtém as contas envolvidas na operação direto do serviço de cache e realiza a operação.
7- Com a operação realizada, persiste as informações no banco, atualiza o estado das contas no serviço de cache e publica no serviço de mensageria os eventos ocorridos dessa operação, necessários para que outros sistemas interessados possam consumir e trabalhar.

Resumidamente sem detalhes técnicos profundos, ainda fica muito obscuro e por parte da engenharia, está aberto muitas dúvidas, mas os design das implementações estarão abertas, documentadas e detalhadas junto ao projeto conforme o ciclo de desenvolvimento vai ocorrendo.

Arquitetura e explicação detalhada

Clique aqui e amplie a imagem para melhor visualização

1- Representação de outros sistemas que compõem a solução como um todo, podendo os mesmos terem contextos e responsabilidades diferentes dentro da solução, mas que são downstream ao Core Pay, pois precisam realizar operações financeiras e elas afetam diretamente a conta que o usuário final possui, que esta no dominio, responsabilidade e especialidade do Core Pay.

Por exemplo, realizar ou receber uma transferência interna ou externa, debito automatico, alguma espécie de cobrança, depósito, saldo, extrato e tudo que envolva diretamente o valores financeiros do usuário final, pode ser que passem diversos outros sistemas, como integrações com órgãos reguladores, mas no final acabaram no Core Pay para aplicação na conta alvo.

2- Representação de onde o sistema Core Pay se propõe se encaixar nas possíveis soluções, sendo um sistema core interno, servindo como a principal interface para operações financeiras, que afetam as contas que estão sob seu domínio.

A comunicação poderá ser feita tanto através da interface REST quanto a GRPC, pois ambas interfaces irão expor as mesmas funcionalidades, possibilitando a flexibilidade de optar por uma ou ambas.

Por se tratar de um sistema crítico, seria ideal estar em uma infraestrutura segura, mas sendo totalmente opcional o como e onde o implementar, como por exemplo utilizar VPN ou VPC e etc.

2.1- Não é uma restrição do projeto obrigar a implementação do Core Pay com outros sistemas com diferentes objetivos agindo na borda como dns, load balancers, proxy reverse, api gateway, WAF e etc, mas sim a premissa da flexibilidade de poder implantar o Core Pay como melhor entender e necessitar, podendo fazer suas próprias escolhas baseado em seu contexto, optando por ter essas soluções na borda ou não.

2.2- Não é uma restrição do projeto ditar a forma como implementar o Core Pay, ficando a critério se haverá apenas uma instância, um cluster, em containers, usando kubernetes e etc, dependendo apenas da solução que deseja alcançar com o contexto que estiver inserido.

Mas é necessário prover a infraestrutura de serviços upstream da qual o Core Pay se integra e são essenciais para sua operação.

3- Representam os serviços upstream necessários que uma infraestrutura provisionada para servir o Core Pay precisa ter, sendo a ideia ilustrar esses serviços como interfaces, representando a premissa do projeto de ter a flexibilidade de ser possível implementar o contrato dessas interfaces e utilizar diferentes diferentes serviços quando possível.

Por exemplo, o comportamento necessário para ser alcançado com o serviço de cache estará definido, por padrão o provider padrão será do redis, mas caso o memcached ou outro sistema de cache também possa atender, novos providers podem ser implementados e utilizados, sendo assim para todos os outros serviços.

Além da possibilidade de utilizar diferentes providers/adapters para cada serviço, o Core Pay é burro em relação a infraestrutura provisionada e não impõe nenhuma restrição, apenas precisa utilizar dela para funcionar, mas como é configurada, quais suas características e comportamentos, depende da sua necessidade e o que deseja alcançar, para que assim possa atender os diversos contextos e problemas.

Por exemplo, você pode disponibilizar uma simples instância até algo altamente disponível.

3.1- Representa a interface referente ao serviço da camada de identidade da plataforma/solução como um todo, idealmente responsável por autenticar e autorizar os usuários e clientes da plataforma, não somente do Core Pay.

O Core Pay não tem conhecimento sobre quem são os usuários, clientes, identidade e o que cada um está autorizado a fazer, apenas tem domínio das permissões definidas para realização de suas operações, sempre utilizando o serviço responsável por autenticar e autorizar para validar a autenticidade da identidade e se tem autorização/permissão para fazer a operação solicitada.

Inicialmente o provider padrão será baseado em OIDC/OAUTH2 providers.

3.2- Representa a interface referente ao serviço de cache, sendo um dos mais importantes e críticos, base para a estratégia de “in-memory database”, que tem o objetivo de alta performance com baixa latência e alto throughput nas operações financeiras.

O design idealizado lida com problemas de concorrência, consistência e uso otimizado e correto da memória.

No caso do serviço de cache, como uma característica da arquitetura do Core Pay, escalar e alcançar alta disponibilidade será utilizado shards, distribuídos entre diferentes instâncias do serviço, sendo assim necessário provisionar um cluster com as características necessárias para alcançar a escala desejada.

Inicialmente o provider padrão será baseado no Redis.

3.3- Representa a interface referente ao serviço de mensageria, utilizado para processamento e comunicação assíncrona, interface dos eventos ocorridos do Core Pay, sendo um componente muito importante para o processamento sincronizado das operações financeiras.

O Core Pay, na proposta inicial da arquitetura, é tanto o produtor quanto um dos consumidores de suas próprias mensagens, sejam comportamentos primários como operações financeiras ou após, estimulados por eventos próprios de comportamentos que ocorreram, como notificar que uma transação financeira ocorreu com sucesso.

Inicialmente o provider padrão será baseado no RabbitMQ.

3.4- Representa a interface referente ao serviço de armazenamento/persistência, a base de dados do Core Pay, por exemplo, onde é efetivado o resultado das operações financeiras após serem processadas com sucesso.

Inicialmente o provider padrão será baseado no Postgresql.

4- Outros sistemas internos downstream que são consumidores dos eventos publicados pelo Core Pay e precisam fazer alguma operação específica quando eles ocorrem, tendo o serviço de mensageria como base na comunicação de forma flexível.

Por exemplo, uma transação que ocorrera de forma interna para externa, quando ela ocorrer, uma mensagem será publicada como evento para notificar que o montante a ser transferido internamente para outra instituição/banco externo, internamente foi subtraído, agora falta esse valor chegar até a conta beneficiária, sendo usando esse evento como estímulo em um outro sistema que irá consumir e finalizar a transação.

Observabilidade

A observabilidade do sistema e da plataforma é algo crucial, não explícito e ilustrado na big picture da solução, mas é uma característica por design, onde se encaixaria na infraestrutura para suportar o Core Pay como parte do conjunto de serviços necessários, porém é uma parte complexa de alcançar uma flexibilidade da qual possa utilizar diferentes providers como os demais serviços, por existir diversas soluções que funcionam de forma específicas e muitas delas proprietárias.

Com essa situação, o objetivo ainda é alcançar características de observabilidade de forma que seja possível ter uma maior flexibilidade na escolha das soluções de forma que seja vendor-agnostic, para isso a premissa será se apoiar na OpenTelemetry, começando por estudar os componentes que seguem e implementam a especificação e caso ainda não estejam maduros o suficiente, buscar implementar nós mesmos a especificação, contemplando:

Structured logging
Monitoring
Tracing
Metrics
APM

Pontos de falha

Tratasse de uma sistema muito crítico, onde o contexto para qual está sendo projetado como solução tem metas altíssimas de SLOs e SLAs, sendo assim muito importante entender dos pontos fracos da solução, quais são os comportamentos e características esperadas por parte do sistema em situações de falhas de si ou de uma integração, para avaliar a viabilidade do uso do sistema como uma solução, estar ciente do que o sistema se propõe, estar preparado e tomar as devidas medidas, principalmente para provisionar uma infraestrutura robusta, pensando na disponibilidade, situações de falhas, em estratégias de fallbacks, failover, evitar single point of failure e outros.

Core Pay

O sistema tem como base dependências muito críticas que são essenciais para suas funcionalidades, mas pela dinamicidade do contexto a única garantia é que possivelmente em algum momento poderá haver alguma falha por parte do Core Pay ou na infraestrutura de serviços, seja pela a ocorrência de uma degradação, eventual indisponibilidade parcial ou completa , mudança na topologia, algum problema referente a rede e outros.

Tendo isso em mente, fora situações onde o próprio Core Pay é o ponto de falha, o mesmo terá a premissa de por design ser resiliente e tolerar falhas, podendo se manter disponível ou parcialmente, mas de alguma forma degradado, pois em situações onde o ponto de falha é algum dos serviços que é uma forte dependência, possivelmente parte das funcionalidades não poderão ser operadas.

Authentication and Authorization server

Sendo o serviço responsável por identificar os solicitantes e permitir que possa ser feita a operação desejada, todo throughput do sistema passará por ele antes de qualquer operação.

Caso o Core Pay não consiga a garantia sobre a identidade e o que a mesma tem permissão para fazer, seu comportamento padrão será tolerar a falha com o serviço, não operando nenhuma funcionalidade, aceitando novas solicitações, respondendo que não pode processá-las naquele momento, ficando parcialmente disponível, mas mantendo a segurança, confiabilidade e integridade, até que não tenha mais falha e consiga garantir o processo novamente.

Cache service

Sendo o serviço responsável por dar vida a característica de “in-memory database”, que tem o objetivo de alta performance com baixa latência e alto throughput nas operações financeiras, é parte do backbone das funcionalidades referente às operações financeiras e outras.

Caso o Core Pay não consiga utilizar a estratégia de “in-memory database” por padrão, irá tolerar a falha com o serviço de cache, aceitando novas solicitações, respondendo que não pode processá-las naquele momento nas seguintes situações:

Solicitações de operações financeiras que envolvam escrita.
Que por design exija exclusivamente o uso do serviço de cache.

Onde demais operações como operações financeiras que envolvam apenas leitura e outras que por design não exija exclusivamente o uso do serviço de cache, será feito a tentativa de fallback para o banco temporariamente até a resolução do ponto de falha, mas apenas será sucesso caso a latência seja aceitável e o banco disponível, não onerando completamente a disponibilidade, onde do contrário, sem serviço de cache e banco, o sistema ficará praticamente indisponível.

A decisão é em prol de garantir a disponibilidade e performance do sistema.

Queue service

Sendo o serviço responsável pela comunicação e processamento assíncrono do sistema, que tem como um dos usos principais nas operações financeiras de escrita, outras operações processadas assincronamente e a comunicação/notificação de outros sistemas, a outra parte do backbone das operações financeiras, mas o sistema quase todo.

Caso o Corey Pay não consiga utilizar o serviço de mensageria, irá tolerar a falha com o serviço, não operando nenhuma funcionalidade que o envolve, aceitando novas solicitações, respondendo que não pode processá-las naquele momento, ficando parcialmente disponível, mas mantendo a consistência, durabilidade, integridade e confiabilidade.

Database

Sendo o serviço responsável pela persistência, logo a escrita e leitura base do sistema, onde todas suas informações estão armazenadas.

Caso o Corey Pay não consiga utilizar o banco de dados, irá tolerar a falha com o mesmo, não operando nenhuma funcionalidade que exija a comunicação direta com o banco, apenas possíveis leituras que ainda estejam retinas temporariamente e ainda confiáveis no serviço de cache caso o mesmo esteja disponível.

Parcialmente disponível nessa situação, mas mantendo a consistência, durabilidade, integridade, confiabilidade e atomicidade.

Evolutiva

Essa é a solução inicial, que tem como objetivo estar preparada para evoluir com facilidade conforme necessário, logo provavelmente não será exatamente a mesma conforme for ser desenvolvida.

Um dos pontos interessantes é que inicialmente será um monolito modular, mas com possíveis intenções da quebra em diferentes serviços menores dependendo do resultado da primeira versão na fase experimental do projeto, caso seja validada positivamente e venha a amadurecer, em sua versão seguinte isso pode vir a acontecer.

Conclusão

Com a base da solução em mente, o direcionamento agora é para iniciar o desenvolvimento, onde a ideia é que para cada entrega seja feito um novo artigo da engenharia por trás, mas todo ciclo ocorrerá no aberto no github, ferramenta a ser escolhida para colaboração e documentação e demais outras, tendo mais informações no próprio repositório do projeto.

Agradeço por sua atenção, fique a vontade para comentar, inteirar e acompanhar mais sobre o projeto:

[ARCHIVDED] Projeto e-Money: Arquitetura

Guilherme Marcial — Mon, 03 Aug 2020 15:20:53 +0000

Esse projeto foi reformulado, agora é o: https://dev.to/gmarcial/core-pay-solucao-5af5

Avisos:

[0] O assunto principal do artigo será a arquitetura do projeto e-Money, onde apenas conterá um resumo sobre o projeto em sí, sendo imprescindível acessar ao repositório do projeto: https://github.com/gmarcial/e-money para conhecer a fundo sobre e não se perder durante a leitura.

[1] Por hora o projeto apenas irá contar com o desenvolvimento e entrega do backend, ficando aberto a possibilidade das demais partes como clientes mobile e web, como contribuição de outros desenvolvedores que venham a ter interesse.

Projeto:

O e-Money é uma solução para um problema fictício, com o objetivo de além a conclusão do meu curso, ser um laboratório de estudos para evolução profissional e portfólio do meu trabalho.

Tem como premissa ser open-source, aberto desde o início, podendo a sua evolução ser acompanhada e ter um aprofundamento sobre em seu repositório no github.

O nome do projeto vem do seu próprio valor monetário, que são créditos eletrônicos com a finalidade servir de moeda dentro da plataforma, onde é transacionada e utilizado para realização de pagamentos.

O e-Money em sua base é um sistema de pagamentos em comum de serviços de entidades que pertencem e participam da plataforma, tendo os usuários como consumidores, que pagam os serviços utilizando a moeda e-Money.

Para um serviço estar disponível para pagamento na plataforma, é preciso se integrar ao hub.

Ex:

Um serviço como o de transporte circular, caso seja participante da plataforma, poderá ser pago com a moeda e-Money.

O desafio

Mesmo este sendo meu primeiro artigo, tenho como objetivo o desafio de registrar o ciclo de desenvolvimento deste projeto, compartilhando não somente as soluções e resultados, mas buscando demonstrar todas as decisões tomadas durante o processo, resultando em um histórico da evolução e portfólio, pois estará aberto a feedback, discussões, compartilhamentos, contribuições e tudo aquilo que venha agregar.

O ciclo é composto pelas seguintes etapas:

Design, develop, test and deploy

Começando pelo design da solução como um todo, que é a proposta deste artigo, ficando os demais registros para respectivas entregas das features, onde ficarei de decidir sua granularidade, podendo vir com um ou mais temas ao mesmo tempo.

Esse artigo tem como objetivo apresentar e explicar a arquitetura inicial projetada, onde provavelmente irá evoluir durante o caminho.

Justificativa:

Durante o ciclo de vida da aplicação, ele consequentemente irá mudar, em vez de ser um sofrimento, podemos preparar para que sejam evoluções.

Essas evoluções podem ser funcionalidades novas, novos entendimentos não claros inicialmente, novos problemas, novas capacidades e etc.

O contexto muda e é preciso que a aplicação acompanhe.

Para que essa capacidade seja alcançada, é necessário alcançar outros que estão compostos:

Modifiability:

Ser facilmente modificável, onde é adaptado com facilidade.

Modularity:

É composto de componentes coesos, desacoplados e independentes uns dos outros, onde são compostos, trabalhando juntos para construir o todo.

Simplicity:

Lidar com problemas complexos com soluções simples, buscando sempre a complexidade essencial e não acidental.

Negócio

Diversos níveis e aspectos da aplicação, sendo primária ou terceiras, podem acarretar em uma situação dessa.

Security

Conceito:

A aplicação deve ter medidas da qual se mantenha protegida contra ataques e ações maliciosas que venham explorar e causar danos ao negócio e clientes.

Justificativa:

Aplicações financeiras são muito visadas por criminosos, pelo fato de que podem conseguir ganhos ilícitos ao explorá-las, sendo necessário proteger a aplicação nos diversos níveis e manter uma política e cultura de segurança, conscientizando os envolvidos e até mesmo uma área específica para cuidar da segurança, famosas equipes red e blue.

Availability

O sistema varia os comportamentos que são configuraveis conforme os parametros passados na configuração, não ficando estatico a um unico contexto, podendo alcançar adaptações de forma flexivel, sem muito trabalho.

Justificativa:

Por base os sistemas precisam se adaptar em diferentes contextos, como na implantação em ambientes diversos, que tem diferentes requisitos, mudar um fluxo ou operação a partir de um paretro e etc.

Para que não precisemos fazer alterações a nivel de codigo para adaptar a qualquer uma dessas situações a gente identifica e implementa esses pontos de forma que sejam configuraveis, tendo apenas que alterar os parametros para se adaptar.

Fault Tolerance

Conceito:

Na ocorrencia de falhas, os impactos causados na aplicação devem refletir proprocionalmente a sua gravidade, onde uma falha simples não deve deixar a aplicação inoperavel, mas apenas onerar a parte onde ocorreu a falha.

No caso da indisponibilidade de um sistema upstream, mesmo que as operações dependentes do mesmo não serem operaveis, as demais que não dependem, devem operar normalmente, lidando de uma forma agradevel com a degradação parcial(graceful degradation) ou total.

Justificativa:

Falhas acontecem, apenas na maioria da vezes não sabemos quando, para isso devemos preparar o sistema para lidar com a falha, seja a nivel de design/implementação, infraestrutura e recursos computacionais, acoplamento dos componentes e etc, buscando ter isso como um comportamente natural, ação automatizada e em situações extremas, manualmente com a intervenção humana.

Scalability

Conceito:

A aplicação é projetada para atender o aumento ou diminuição dos recursos computacionais conforme a carga de trabalho, sendo possivel os alterar conforme a necessidade para continuar disponivel e realizando o trabalho, onde a escala pode ser horizontal(scale out) que ocorre com o aumento de nós em um cluster ou vertical(scale up) que ocorre com o aumento de recursos computacionais de unico mesmo nó, como mais memoria ou nucleos.

Justificativa:

Toda aplicação tem uma carga de trabalho base, mas que ele pode variar em momentos esperados como em picos em momentos padrões ou aumentar conforme o negocio cresce.

Cada aplicação tem sua caracteristica, como uma aplicação foodtech tem o aumento em horarios de alimentação e backfriday para e-commerces e marktplaces.

Fora momentos que podem ser inesperados, onde a aplicação deve estar preparada para escalar e aguentar a carga.

Performance

Conceito:

Medida que representa o desempenho da aplicação na realização de suas operações, seja quanto tempo levou, quantos operações foram feitas em um determinado periodo e quantidade de recursos utilizados.

Quão mais rapida realiza as operações, mais operações realiza em um determinado periodo e utilizando menos recursos, mais performatica, tendo uma melhor desempenho.

Justificativa:

Certas operações necessitam de um cuidado especial em relação a performance, por exemplo, pode exigir um tempo de resposta baixo e que sejam realizadas uma quatidade X de operações em um periodo curto de tempo para que esteja disponivel.

Outras podem exigir um melhor uso dos recursos computacionais, otimizando as operações para que use apenas o necessario, diminuindo custos, pois parte dos recursos seriam redistribuidos para as demais operações da aplicação.

Arquitetura:

Amplie a imagem para visualizar melhor

A arquitetura por parte dos clientes, inicialmente é composta somente por primários que farão o interfaceamento com os usuários finais, tendo cada um deles uma finalidade diferente, pois cada contexto tem suas necessidades, sendo web para o back office onde os administradores irão gerenciar a plataforma, já os cidadãos, utilizam as plataformas mobile para acesso e gerenciamento de sua conta e máquinas de pagamento para pagamento dos serviços.

Com objetivo de evitar acesso direto aos recursos, principalmente a api, a frente de todas requisições terá um proxy reverso que pela sua maturidade a escolha foi o nginx. Toda comunicação passará por ele, será o filtro inicial antes do redirecionamento, realizando alguns trabalhos gerais e genéricos em relação a requisição, intermediando entre os recursos internos e os requisitantes.

Uma das partes mais importantes é a api rest utilizando em seus contratos de comunicação o formato json, responsável pela operacionalização da plataforma, aplicando as regras de negócio.
Irá servir aos clientes, estará integrado ao vault para gerenciamento dos segredos que estarão envolvidos na infra e em algumas das regras de negócio, onde iremos nos aprofundar mais a frente em próximos artigos, e o banco de dados postgres para persistências das informações, tanto para a api, quanto ao vault, podendo adotar abordagens relacional e não relacional.

O projeto tem como premissa ser cloud native, que será optado entre a google cloud e a digital ocean, tendo como restrição o custo financeiro final, por se tratar de um projeto sem fins lucrativos e financiado por fundos pessoais.

Todo o projeto por questões de segurança estaria em uma VPC e sub-redes para não estarem expostos diretamente a internet, além de ter o proxy como um gateway, criando um ambiente seguro, gerenciado em várias etapas e claro em containers docker.

Agora vamos falar detalhadamente de cada parte.

Clientes:

Amplie a imagem para visualizar melhor

Todos clientes primários por fim vão representar um usuário final, seja um administrador ou um cidadão.

A responsabilidade do administrador é gerenciar a plataforma, muitas das vezes tendo um terminal de trabalho onde não caberá somente a responsabilidade do gerenciamento da plataforma a e-Money, podendo também trabalhar com outras finalidades, sendo a web uma ótima plataforma para o back office.

Já para os cidadãos que utilizam a plataforma como consumidores finais, que precisam de uma maior praticidade e mobilidade para gerenciarem suas contas de qualquer lugar, a escolha são as plataformas mobile.

Por segurança a plataforma só aceita clientes primários, os quais confiá, sendo autenticados e autorizados para interagir com os serviços, passando pelo processo de MTLS, além do tunelamento seguro para comunicação.

Além da parte do cliente, outro nível de segurança é por parte do usuário final que o utiliza, precisando também se autenticar, para sua identificação durante o ciclo de uso e autorização das ações dentro da plataforma, utilizando tokens de identidade(id token) e acesso(access token).

Quando existir situações sem autenticação do usuário final, MTLS será o suficiente.

Cliente de pagamento:

Amplie a imagem para visualizar melhor

O cliente especifico para pagamentos é por onde as entidades parceiras utilizaram para realizar as transações referente ao pagamento dos serviços consumidos e somente por eles que os mesmos ocorreram.

Além de se autenticar e ocorrer a tunelização da comunicação com MTLS, esse tipo de cliente em especial, irá representar uma entidade da qual efetuará as transações através dele, sua identidade tem que corresponder a da qual foi configurado e certificado.

Somente será autorizado transações quando autenticado e corresponder a entidade para qual foi configurada, logo sua identidade é previamente feita e ligada a sua configuração na plataforma pela administração.

Proxy reverso:

Amplie a imagem para visualizar melhor

O proxy intermedia a comunicação, é quem conhece e redireciona para os responsáveis por lidar com as requisições, podendo aplicar alguma medida manipulando a requisição, segurança, balanceamento e filtro, como só aceitar clientes válidos e confiáveis antes de redirecionar, pois é o primeiro a receber a requisição.

Isolando os recursos do mundo externo, ele é único conhecido e está a frente de toda comunicação, mantendo os demais seguros.

Além de segurança, ele pode contribuir para performance e outras medidas, como cache, filtros e etc. Todos as requisições são intermediadas por ele, podendo fazer a manipulação e ações na entrada e saída, conforme as possibilidades de configuração do nginx.

Outra solução que poderia se encaixar muito bem seria um api gateway, sendo alguns baseados propriamente em cima do nginx.

Contrato com a api:

O consumo da api deve ser claro, tento bem modelado os recursos, expressando seus contratos e principalmente expor o estado, resultado de cada ação e operação, para que diante disso o consumidor possa ficar ciente e a partir disso possivelmente realizar os comportamentos corretos conforme a situação.

Para isso a api deve estar bem documentada, deixando explícito seus recursos, ações, e como realizar e seus comportamentos esperados, além disso um contrato em comum das respostas, seus estados e regras conforme as situações.

Base:

Status code

Estado da ação

Descrição

Resultado

Ex:

Casos 2xx:

Status code: 201
{
  "state": "success",
  "description": "A conta foi aberta com sucesso",
  "result": {
    "resource": "accounts/8129391"
  }
}

Casos 4xx:

Status code: 400
{
  "state": "Dados invalidos",
  "description": "A conta não pode ser aberta, ",
  "result": {
    "messages": [
        {
          "property":"...",
          "value":"..."
        },
        {
          "property":"...",
          "value":[
              {
                "property":"...",
                "value":"..."
              },
              {
                "property":"...",
                "value":"..."
              },
              {
                "property":"...",
                "value":"..."
              }
            ]
        },
        {
          "property":"...",
          "value":"..."
        }
      ]
  }
}

Casos 5xx:

Status code: 500
{
  "state": "Erro inesperado",
  "description": "Ocorreu um erro interno ao tentar processar esta ação"
}

Persistencia dos dados:

Amplie a imagem para visualizar melhor

O RDBMS escolhido será o postgresql, além da sua maturidade, popularidade, eficiência e extensibilidade, aproveitar tanto da sua abordagem relacional, quanto a não relacional com a feature de persistências de arquivos json e jsonb, podendo obter também uma abordagem de documentos.

Toda comunicação com o banco será segura através de conexões utilizando TLS.

Estando em avaliação referente a restrição financeira se será optado por uma abordagem de um serviço gerenciado nas clouds propostas, ou não.

Vault:

Amplie a imagem para visualizar melhor

A aplicação lidará e gerenciará segredos, seja por parte da infraestrutura quanto de algumas regras de negócio, além de armazenar, também gerar.

Não somente os segredos, mas lidar corretamente com criptografia que terá uma grande atuação no projeto.

Para que não precise implementar na mão ou utilizar soluções não tão confiáveis, o vault vem como solução especializada e madura nisso, sendo utilizado como um serviço integrado ao projeto e o melhor, aplicando esses conceitos críticos de forma correta, além de abrir outras possibilidades, pois o mesmo tem mais features do que está descrito aqui e de uma forma mais aprofundada.

A persistência das informações ocorrerá a partir da utilização de um banco postgres próprio e isolado.

Considerações finais

Agradeço por todos que leram até o final, é um passo importante para mim estar escrevendo meu primeiro artigo e estar compartilhando minha experiência nesse projeto.

Provavelmente nos próximos capítulos já será sobre a primeira entrega, dando início ao desenvolvimento.

Novamente, estou aberto a feedbacks, discussões, trocar uma ideia, compartilhar, contribuições e tudo aquilo que venha agregar e contribuir para a evolução contínua.

Obrigado.