Criar uma API Rest e estruturar micro serviços não precisa ser algo difícil. Nesta sequência de artigos vamos entender desde a concepção de uma infraestrutura baseada em micro serviços até o desenvolvimento completo de uma aplicação.
O que vamos ter nessa aplicação?

Veja o diagrama:

Baseado no diagrama vou explicar a motivação por trás de cada item e como vamos trabalhar com ele.

É importante também que você entenda o que vamos levar em consideração como regras de negócio.

Sim, regras de negócio. Ser programador não é só sobre sair criando códigos e scripts de automatização. Você precisa resolver problemas! Nada melhor que entender como o problema surge para conseguir uma saída para resolvê-lo.

Vamos aos itens do diagrama.

CDN (Frontend Statics)

É, essencialmente, nosso frontend. Você pode entendê-lo como a aplicação em HTML e CSS, React, ou seja, lá qual o framework/lib que você queira usar (Vamos usar o React).

Containers

Esse grupo de itens corresponde às APIs que vamos criar separadamente, cada qual com suas respectivas responsabilidades.

Transactions API

Essa é nossa API de transações (ou pagamentos e recebimentos).

Essa API vai manter o histórico de transações de cada usuário e conta de usuário.

Para simplificar, associe a um banco. Como se você fosse o usuário e tivesse contas nesse banco, algo como uma conta corrente e uma poupança.

Essa API vai conter algo semelhante ao seu extrato.
Vamos às regras de negócio da Transactions API

Regra 1: Só podemos cadastrar transações, não podemos excluí-las.

Isso significa que uma devolução ou estorno deve ser uma nova transação com o valor reembolsado.

Regra 2: Toda transação deve ser diretamente relacionada a um usuário e a uma conta deste usuário.

Isso significa que uma transação deve ter um usuário e uma conta deste mesmo usuário como origem/destino.

Regra 3: Toda transação deve ter um tipo, como entrada ou saída. Além de ter o valor, em centavos, da transação, bem como o método de pagamento (Ex.: pix, débito, doc ou ted).

Users API

Essa é a nossa API de usuários.

Essa API vai manter os dados dos clientes. Aqui teremos e-mail, senha, data de criação e atualização de conta.
Serão somente esses dados apenas para fins didáticos.

Vamos às regras de negócio da Users API

Regra 1: Todo usuário deve fornecer um e-mail e uma senha para cadastro.

Isso significa que ambos campos de identificação do usuário são obrigatórios.

Regra 2: Toda atualização, adição de transação ou “abertura de conta” deste usuário deve registrar a data de atualização do usuário.

Isso significa que nosso campo updated_at sofrerá uma atualização a cada ação de escrita do usuário.

Accounts API

Essa é a API de contas de usuário.
Nela vamos manter o tipo da conta do usuário (se é corrente ou poupança), o balanço, o número e o usuário dono da conta.
Vamos às regras de negócio da Accounts API

Regra 1: Toda conta deve ter um tipo. Imagino algo como conta corrente, conta poupança.
Isso significa que não podemos permitir um usuário criar uma conta sem solicitar que seja, conta-corrente ou conta-poupança.

Regra 2: Toda conta deve ter obrigatoriamente um dono.
Isso nos diz que também não podemos permitir a criação de uma conta sem que haja um usuário envolvido.

Regra 3: O balanço da conta deve ser recalculado sempre que for recebido um evento de nova transação.

Isso significa que sempre que houver uma nova transação nossa API de contas vai “ouvir” este evento e recalcular o balanço baseado nesta nova transação.

Database

Geralmente, micro serviços consomem suas próprias bases de dados. Nesta aplicação vamos utilizar uma única base de dados separando apenas as tabelas.

Isso não é algo incomum em grandes sistemas que estão no processo de migração de um monólito. É uma etapa encontrada durante o processo de estrangulamento do sistema, mas isso é assunto para outro momento.

Cada micro serviço deve ser independente de qualquer outro. Vamos trazer isso para nosso modelo. Caso nossa API de transações cair por qualquer motivo, a API de usuários ou de contas devem se manter funcionando de forma independente.
Algo que é parcialmente verdade em nosso design atual. Caso o usuário queira saber seu saldo total não é possível se nossa API de contas venha a cair.

Para resolver isso, deveríamos “clonar” o balanço das contas do usuário dentro da base de usuários. Isso tornaria nossa aplicação independente e caso a API de contas fique fora do ar, nosso cliente ainda consegue ver seu saldo atual.

Ah! mas isso gera duplicidade de dados, né?! Correto!

Esta é outra dúvida que acontece quando falamos sobre micro serviços independentes. Se você está no início de sua startup não sei se você deveria considerar usar micro serviços, quando digo não sei, na verdade, quero dizer não aconselho usar.

Micro serviços são caros. Você deve levar em conta a utilizar micro serviços em situações específicas. Por exemplo, quando seu sistema está tão grande a ponto de ser muito custoso (em termos de desenvolvimento, não financeiro) para qualquer implementação nova.

Enfim, este é outro tema que dá um artigo completo.
Quanto às nossas bases de dados, simplesmente teremos três tabelas, usuários, transações e contas. Algo como o seguinte diagrama:

Fila e eventos

Vou te mostrar como trabalhar com fila e eventos não é um monstro de sete cabeças.

Fila, como o próprio nome já diz é uma fila! (Uau!)

Em essência, vamos adicionar um evento na fila e esquecê-lo lá. Outra parte da nossa aplicação vai ficar monitorando a fila, pegando os eventos (também conhecidos como mensagens) e processando os dados recebidos.

Para essa fila de eventos (ou mensagens) vamos utilizar RabbitMQ.

Espero que fique calmo, não é algo difícil de utilizar. Você verá que é algo extremamente simples.

É importante salientar que é diferente utilizar de implantar. RabbitMQ é algo complexo para se lidar quando se trata de infraestrutura. Porém, como desenvolvedor é algo relativamente simples.

Vamos à mão na massa na parte II. Espero você lá.