Cronos Cashflow
Plataforma de planejamento financeiro e visibilidade de fluxo de caixa: compromissos futuros, lançamentos recorrentes e projeções.
Contexto
Produto próprio. Uma plataforma de planejamento financeiro voltada a dar visibilidade sobre obrigações futuras, lançamentos recorrentes e projeções de fluxo de caixa, o tipo de informação que costuma viver espalhada em planilhas.
Desafio
Domínio financeiro não tolera ambiguidade: um lançamento recorrente projetado errado corrompe toda a previsão. O desafio é modelar recorrência, projeção e realizado de forma que o número na tela seja auditável até a origem.
Meu papel
Arquitetura de software, desenvolvimento backend e frontend, modelagem do domínio financeiro, autenticação, deploy e infraestrutura.
Responsabilidades
- Arquitetura de software e modelagem do produto.
- Backend em PHP 8 e banco relacional.
- Interface web em Next.js.
- Autenticação e controle de acesso.
- Deploy e infraestrutura em containers.
Restrições
- Correção do domínio financeiro acima de velocidade de entrega.
- Autenticação precisa servir a três clientes distintos: web, aplicativo móvel e a aplicação legada.
- Produto próprio, com time reduzido: a arquitetura precisa caber em quem a mantém.
Arquitetura
- Backend organizado em módulos separados (aplicação, API, biblioteca comum e camada de console), com o console hospedando rotinas e comandos agendados.
- Autenticação por JWT, servindo web e aplicativo móvel a partir da mesma API.
- Interface web desacoplada, consumindo a API, com separação entre domínio e apresentação.
- Aplicativo móvel em React Native compartilhando a mesma API do backend.
- Ambiente containerizado com Docker e docker-compose.
Principais decisões técnicas
Manter um único backend servindo API para web e mobile, em vez de dividir em serviços.
Por quê
O domínio é coeso e o time é pequeno. Um monolito modular bem organizado entrega a mesma clareza de fronteiras sem o custo operacional de distribuir o sistema.
Trade-offs
- Escala vertical antes de horizontal.
- Exige disciplina interna de módulos. Sem isso, o monolito vira bola de lama.
- Reduz drasticamente a superfície de operação: um deploy, um banco, um lugar para depurar.
Autenticação via JWT em vez de sessão de servidor.
Por quê
A mesma API serve navegador e aplicativo móvel. Sessão com cookie funciona bem no browser e mal no mobile; JWT dá um mecanismo único para os dois clientes.
Trade-offs
- Revogação de token exige estratégia própria: não basta destruir a sessão.
- O token precisa de tempo de vida curto, o que traz a complexidade de renovação.
- Em troca, um único fluxo de autenticação para todos os clientes.
Modelar recorrência como regra, não como linhas pré-geradas.
Por quê
Materializar anos de lançamentos futuros no banco engessa a edição: mudar uma recorrência exigiria reescrever todo o histórico projetado.
Trade-offs
- Projeção passa a ser calculada, o que custa mais processamento na leitura.
- Exige cuidado com exceções pontuais dentro de uma série recorrente.
- Em compensação, alterar a regra reflete imediatamente em toda a projeção.
Implementação
- Lançamentos financeiros recorrentes e pontuais.
- Projeção de fluxo de caixa a partir das regras de recorrência.
- Dashboards e relatórios financeiros.
- Controle de acesso por papel.
- Integração de pagamentos via Stripe.
Operação em produção
- Deploy containerizado.
- Rotinas agendadas executadas pela camada de console do backend.
- Operação e suporte sob responsabilidade própria.
Resultados
- Produto em produção, com web e aplicativo móvel servidos pela mesma API.
- Deu visibilidade de compromissos futuros a partir das regras de recorrência, substituindo controle manual em planilha.
- Uma única superfície de autenticação para os diferentes clientes do produto.
Stack
- PHP 8.3
- MySQL
- JWT
- Stripe
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Native
- Docker