pt

Como funciona?

Precisa de ajuda para negócios?

Contacte-nos para um orçamento FinMV personalizado à medida das suas necessidades.

Monolítico ou microsserviço?

O diretor técnico da sua empresa, ao planejar o lançamento de uma plataforma financeira, deverá escolher uma opção de arquitetura de projeto. Quais opções de arquitetura estão disponíveis para ele e qual é melhor escolher?

Comece com a arquitetura mais simples que preserve as fronteiras

Uma nova plataforma de investimentos tem uma equipe, um deployment e um banco de dados. O custo de um sistema distribuído nessa fase vai inteiramente para overhead: chamadas de rede onde uma chamada de função bastaria, consistência eventual onde uma transação bastaria, e uma carga operacional para a qual não há pessoal.

Por isso a implementação padrão é modular: onboarding, ofertas, investimentos, pagamentos, documentos, atendimento e relatórios vivem atrás de fronteiras explícitas dentro de um único sistema implantável. O que a torna modular não é a estrutura de pastas, mas o fato de que cada módulo tem seu próprio contrato, seus próprios dados e seus próprios testes.

Um serviço é extraído quando há um motivo para isso

Um módulo se torna um serviço separado quando existe um motivo concreto, e esses motivos são de negócio, não de moda:

  • escala — uma parte do sistema precisa crescer ou falhar independentemente do resto
  • segurança — uma fronteira precisa de isolamento mais forte do que um módulo dentro de um único processo oferece
  • compliance — um regulador ou uma auditoria exige separação de responsabilidades ou de dados
  • deployment — uma parte precisa ser lançada em outra cadência ou por outra equipe
  • integração — um sistema externo impõe seu próprio perfil de disponibilidade e capacidade
  • organização — equipes separadas precisam ser donas de coisas separadas sem coordenar cada release

Como as fronteiras e os contratos já existem, extrair um serviço é uma operação planejada, não uma reescrita. É esse o ponto: a opção permanece aberta e barata.

Assincronia onde ela se justifica

Trabalho que não deve bloquear o usuário — conciliação de liquidações, geração de documentos, callbacks de provedores, relatórios — passa por filas. Brokers de mensagens como RabbitMQ ou Kafka entram em cena quando a carga ou a topologia de integração justifica, não por padrão. O PostgreSQL continua sendo o sistema de registro; o Redis é usado onde cache de baixa latência ou coordenação são realmente necessários.

O que não fazemos

Não vendemos um monólito, e não vendemos microsserviços. Ambos são respostas a perguntas que ainda não foram feitas. Também não construímos um sistema distribuído só para parecer sério — teatro arquitetural é caro de operar e difícil de repassar.

Sua arquitetura é escolhida a partir da sua escala, das suas obrigações regulatórias, das suas integrações e do tamanho da equipe que vai operá-la — e é projetada para poder mudar quando elas mudarem.