Orena One
O Orena One é o produto de software da Orena 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.
Este registro trata da engenharia do produto: as restrições, as decisões e a arquitetura que as sustentam.
- Software Engineer / produto autoral
- 2026 — atual
- Produto SaaS modular para operações reais
- Product engineering · 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 produto de software 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.
A mesma base de produto é organizada para contextos de operação diferentes, como varejo, serviços, alimentação e saúde. Cada contexto acrescenta módulos e regras próprias sem duplicar o núcleo.
Decisões
Multi-tenant desde o início
O desenho estabelece que todo dado pertence a um tenant, isto é, a um negócio, e trata o isolamento como regra transversal da plataforma, não como um cuidado repetido em cada tela ou consulta.
É uma decisão de arquitetura. O que está verificado é o comportamento coberto pelas suítes de isolamento, com o escopo e o limite descritos em Evidência e limites.
Mais custo de modelagem e de teste no começo. Em troca, o desenho prevê que novos negócios compartilhem a mesma base de produto, cada um com seus dados e sua configuração, e busca reduzir a necessidade de código específico por operação.
PDV projetado para operar 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.
Diagrama conceitual: não é topologia de implantação nem evidência de operação. A seta indica o sentido do fluxo de sincronização, não confirmação de entrega.
Limite conhecido: resiliência da tentativa no cliente após recarregar ou interromper a página, em validação e ainda sem prova pública.
- 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.
Evidência e limites
Cada afirmação abaixo aponta para o que a sustenta e para o que ela não mostra. O que não tem evidência não aparece aqui como resultado.
O acesso por identificador a recurso de outro tenant é recusado, sem efeito no outro tenant e sem associação cruzada, nos módulos cobertos pela suíte.
- Suítes de isolamento entre tenants do produto, executadas e aprovadas. Verificada em teste em 16/10/2026 · Testes automatizados · repositório privado
- Comportamento verificado em teste, módulo a módulo. Não é evidência de operação com vários clientes em produção.
Problema, decisão e abordagem
- Vários negócios usam a mesma plataforma e nenhum pode alcançar os dados de outro.
- O escopo por tenant é regra da plataforma. Os testes tentam o acesso direto: com a sessão de um tenant, ler, alterar ou associar recursos de outro por identificador.
No servidor, a finalização de venda é idempotente em teste: o replay não duplica crediário, estoque, ledger nem auditoria, e a corrida no índice único e a nova tentativa após rollback não duplicam a venda.
- Suíte de idempotência da finalização de venda no servidor, executada e aprovada. Verificada em teste em 16/10/2026 · Testes automatizados · repositório privado
- Cobre o servidor, em ambiente controlado. A identidade da tentativa no cliente após recarregar ou fechar a página é um limite conhecido, ainda em validação e sem prova pública: nesse cenário, uma nova tentativa pode não ser reconhecida como a mesma venda. Não cobre rede real nem operação em campo.
Problema, decisão e abordagem
- Fechar uma venda quando a conexão cai ou o pedido é repetido, sem duplicar a venda nem os efeitos dela. O problema tem duas partes: o servidor reconhecer a repetição e o cliente reenviar a mesma tentativa depois de uma interrupção.
- Cada finalização carrega um identificador de requisição, único por tenant. No servidor, um reenvio com o mesmo identificador é reconhecido como a mesma operação, e não como uma venda nova.
O ciclo de sincronização Edge → Cloud funciona ponta a ponta em teste, com requisições reais.
- Suíte do worker de sincronização (unitária e ponta a ponta), executada e aprovada. Verificada em teste em 16/10/2026 · Testes automatizados · repositório privado
- Ambiente local e controlado. Não cobre rede real nem volume de dados e não prova o funcionamento em instalações de clientes.
Problema, decisão e abordagem
- Levar para a Cloud as operações registradas localmente, com autenticação e confirmação de recebimento.
- O worker do Edge envia as operações à Cloud por HTTP, com autenticação e confirmação (ACK). O teste ponta a ponta usa a Cloud como servidor HTTP de verdade, sem mock de HTTP, autenticação, endpoint nem ACK.
A telemetria operacional e o verificador de saúde têm contrato testado, inclusive a degradação de um bloco sem derrubar a resposta.
- Suítes de telemetria operacional, de envio do Edge e do verificador de saúde, executadas e aprovadas. Verificada em teste em 16/10/2026 · Testes automatizados · repositório privado
- Verifica o contrato dos dados e do verificador. Não mostra cobertura de alertas nem operação com monitoramento contínuo.
Problema, decisão e abordagem
- Mostrar o estado de uma instalação sem que uma falha na própria coleta esconda ou falseie o que está acontecendo.
- A telemetria é somente leitura e degrada por bloco: se uma coleta falha, o bloco aparece como ausente, nunca como zero, e a resposta continua. Um verificador de saúde agrega checagens com resultado e código de saída definidos.
O que este registro não afirma
- Este registro não afirma operação comercial em produção, clientes pagantes, métricas de uso, recuperação de desastre comprovada em campo nem escala.
- O produto está em preparação e validação para operação piloto: o que se afirma aqui é arquitetura e comportamento verificado em teste, não resultado medido em operação.
- O repositório do produto é privado. A evidência são testes executados pelo autor, e não artefatos que terceiros possam auditar neste site.
Resultado e aprendizado
Resultado até aqui
O resultado até aqui é uma base arquitetural cujas partes centrais têm verificação em teste: idempotência da finalização de venda no servidor, isolamento entre tenants, sincronização Edge → Cloud e telemetria com contrato testado. A seção anterior traz, para cada uma, a evidência e o limite. Não há, neste registro, medição de operação real.
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.