Orena One
Plataforma SaaS modular, em evolução, para a operação de pequenos negócios: venda no balcão, financeiro e regras de negócio no mesmo sistema, que precisa continuar funcionando quando a internet não funciona.
- Software Engineer / projeto autoral
- 2026 — atual
- Plataforma SaaS modular para operações reais
- SaaS · Multi-tenant · Edge/Cloud · Offline · PDV · Regras de negócio
Este registro descreve problema, decisões e arquitetura. Não inclui dados de operação, nomes de estabelecimentos nem números de uso.
Problema
Pequenos negócios costumam operar com ferramentas que não conversam entre si: um sistema de caixa, uma planilha para o financeiro e anotações para o que não cabe em nenhum dos dois. Cada ferramenta resolve uma parte, e a conciliação entre elas fica com quem opera.
O problema técnico central não é registrar uma venda. É registrar uma venda quando a conexão cai, sem perder a consistência com o financeiro e sem exigir que alguém refaça o trabalho depois.
Contexto
O Orena One é um projeto autoral, iniciado em 2026 e em evolução, em preparação e validação para operação piloto. As decisões abaixo descrevem a arquitetura adotada, não uma operação em larga escala.
O ponto de partida é a rotina de pequenos negócios: o caixa não pode parar, a conectividade não é garantida e as regras mudam de um estabelecimento para outro, como formas de pagamento, fechamento de caixa e permissões.
Isso impõe três restrições ao desenho. Vários negócios compartilham a mesma plataforma sem compartilhar dados. O ponto de venda precisa funcionar sem depender da nuvem. E as regras de cada negócio precisam ser configuráveis sem virar código específico para cada um.
Decisões
Multi-tenant desde o início
Todo dado pertence a um negócio (tenant), e o isolamento é tratado como regra da plataforma, aplicada em um único lugar, e não como um cuidado repetido em cada tela ou consulta.
Mais custo de modelagem e de teste no começo. Em troca, novos negócios podem compartilhar a mesma base de produto, com isolamento de dados e configuração própria, reduzindo a necessidade de código específico por operação.
PDV que opera offline
O ponto de venda grava localmente primeiro e sincroniza depois. A camada central recebe os dados quando há conectividade, mas não é um pré-requisito contínuo para a operação do PDV.
A sincronização passa a ser um problema de primeira classe: cada operação precisa ter identidade própria para ser reenviada sem gerar duplicidade.
Edge e Cloud com responsabilidades distintas
O Edge concentra a operação que precisa continuar disponível no estabelecimento. A camada Cloud concentra capacidades centrais que podem operar de forma assíncrona, como sincronização, telemetria e gestão da instalação, e serve de base para a evolução dos serviços centralizados da plataforma.
Por um período, existem duas versões do estado. É preciso definir, para cada tipo de dado, qual lado decide quando há divergência.
Regras de negócio como configuração
As variações entre negócios são expressas como parâmetros dos módulos, e não como ramificações de código por cliente.
Exige limitar o que é configurável. Nem toda exceção vira opção; algumas viram uma decisão de produto.
Arquitetura
A arquitetura separa o que precisa acontecer no balcão, na hora e com ou sem internet, do que pode acontecer depois, na camada central. A descrição é conceitual: componentes e responsabilidades, sem detalhes de implementação.
- Edge — ponto de venda
- Executa a operação do balcão com armazenamento local. Registra vendas e movimentações de caixa sem conexão e mantém uma fila de operações a sincronizar.
- Sincronização
- Envia operações elegíveis do Edge para a camada central quando há conexão. Os fluxos usam identidade e mecanismos de idempotência para que reenvios não transformem a mesma operação em eventos duplicados.
- Cloud — plataforma
- Recebe e organiza dados sincronizados por tenant, concentra telemetria e informações operacionais das instalações e serve de base para capacidades centralizadas da plataforma.
- Módulos
- PDV, financeiro e cadastros evoluem como módulos com fronteiras explícitas, habilitados por tenant.
- Migração de legado
- Entrada de dados vindos de sistemas anteriores, com validação antes de passarem a fazer parte da operação.
- Observabilidade
- O estado de cada ponto de operação, como conectado, offline ou com pendências de sincronização, fica visível para quem opera e para quem dá suporte.
Resultado e aprendizado
Resultado até aqui
O resultado até aqui é uma base arquitetural em que a operação local não depende continuamente da conexão, diferentes negócios compartilham o mesmo produto com isolamento próprio e os dados operacionais podem alimentar as camadas gerenciais sem depender de processos manuais duplicados.
O projeto segue em evolução. Os próximos passos dependem do que a validação para operação piloto mostrar.
Aprendizado
Para o PDV, ausência temporária de conexão não pode ser tratada apenas como falha excepcional; ela precisa fazer parte do desenho operacional. Considerar isso desde o início influencia decisões de persistência, sincronização e consistência.
Em uma plataforma multi-tenant para pequenos negócios, a pressão maior não é escala, é variação: cada negócio opera de um jeito. O trabalho de arquitetura está em decidir o que é regra da plataforma e o que é configuração de cada negócio.