Banco local
O que fica na máquina, por quanto tempo, com que índice e qual o tamanho máximo antes de arquivar. Normalmente SQLite, pelo custo zero de administração.
Método YveTech de Desktop · Etapa 02
Arquitetura local + nuvem
Aplicação desktop bem feita não é a que ignora a nuvem, nem a que depende dela. É a que sabe exatamente o que guardar na máquina, o que enviar, em que ordem — e o que fazer quando a resposta demora ou nunca chega.
A pergunta não é "onde fica o dado". É "quem manda quando os dois discordam"
Sincronização é fácil enquanto tudo dá certo. O projeto se define no que acontece quando não dá.
Ligar uma aplicação desktop à nuvem é simples no dia bom: grava local, envia, confirma, pronto. O trabalho de arquitetura começa no dia ruim — quando a máquina do caixa gravou uma venda, a internet caiu, o supervisor alterou o mesmo pedido pelo painel web e as duas versões se encontram meia hora depois. Sem uma regra decidida antes, o sistema escolhe uma delas em silêncio, e alguém descobre isso no fechamento do mês.
Por isso a etapa produz decisões explícitas, não um desenho bonito: o que é fonte da verdade para cada tipo de registro, o que a máquina pode fazer sozinha e o que exige confirmação do servidor, quanto tempo a fila pode acumular antes de virar alerta, o que acontece com um número de nota quando duas estações estão offline ao mesmo tempo. Cada uma dessas respostas vira comportamento no código e texto no documento de arquitetura.
Também definimos o que o sistema faz de cara feia. Estoque negativo, preço divergente, cadastro que sumiu na origem, relógio da máquina errado — a operação não pode travar por isso, mas também não pode fingir que está tudo certo. A regra de cada caso é decidida com você, com o custo do erro na mesa.
Aplicação que "sincroniza automaticamente" sem regra de conflito não sincroniza: ela escolhe um vencedor em silêncio e você descobre no fechamento.
O que a arquitetura decide
Seis definições que separam uma aplicação que aguenta o dia ruim de uma que só funciona na demonstração.
Fila e reconciliação
A ordem de envio, o número de tentativas, o tempo de espera entre elas e o que fazer com o item que falha sempre.
Regra de conflito
Quem vence quando os dois lados mudaram o mesmo registro — e quais casos, em vez de escolher sozinho, param para uma pessoa decidir.
Contrato com a nuvem
Quais rotas, que formato, que limite de tamanho e como a API se comporta com um cliente que sumiu por dois dias.
Dado em repouso
O que é cifrado na máquina, onde ficam as credenciais e o que sobra num computador que for roubado ou trocado.
Modo degradado
O que a aplicação continua fazendo sem rede, o que ela bloqueia e como avisa o operador sem interromper a fila.
Como a arquitetura é apresentada
Documento curto e legível: quem não programa precisa entender as escolhas que vão custar dinheiro depois.
Como a etapa acontece
De duas a três semanas, terminando com uma prova técnica rodando de verdade.
Classificação dos dados
Registro a registro: o que nasce na máquina, o que nasce na nuvem e o que os dois podem alterar. É essa lista que gera as regras de conflito.
Desenho e decisões
Escolha de banco local, formato de sincronização, política de tentativa e limites. Cada decisão registrada com a alternativa que foi descartada e o motivo.
Prova de conceito
Um protótipo que grava local, perde a conexão de propósito, acumula fila e reconcilia. Arquitetura no papel não prova comportamento.
Validação com a operação
Apresentamos o modo degradado para quem opera. Se a regra que decidimos atrapalha a fila real, ela muda agora — e não depois de pronta.
O que garantimos na arquitetura
Compromissos que valem para todo projeto desktop da YveTech.
- Nada se perde na queda — o que foi confirmado ao operador está gravado antes de qualquer envio.
- Conflito tem dono — toda colisão possível tem regra escrita, e as ambíguas param para uma pessoa.
- Decisões documentadas — o porquê de cada escolha fica no repositório, não na memória de um desenvolvedor.
- Testado sem rede — a queda de conexão é caso de teste, não uma surpresa em produção.
O que não prometemos
Os limites que preferimos dizer antes de assinar.
- Sincronização instantânea — sem rede não há envio; o que garantimos é ordem, integridade e nada perdido.
- Resolver todo conflito sozinho — alguns casos exigem decisão humana, e forçar automatismo neles gera prejuízo silencioso.
- Offline eterno — a máquina precisa reencontrar a nuvem em algum momento; combinamos o limite aceitável de cada caso.
- Servidor desnecessário sempre — quando volume ou regra de acesso exigem um servidor, dizemos — com o custo na mesa.
Onde cada dado costuma morar
Ponto de partida que ajustamos ao seu caso. O que não muda é decidir isso antes de escrever código.
| Tipo de registro | Fonte da verdade | Comportamento sem conexão |
|---|---|---|
| Venda e movimento do turno | a máquina que registrou | grava local e entra na fila; a operação não para |
| Cadastro de produto e preço | a nuvem | usa a última cópia recebida e marca a idade dela na tela |
| Estoque | a nuvem, com reserva local | permite a saída dentro do saldo conhecido e reconcilia depois |
| Permissão e perfil de acesso | a nuvem | mantém a sessão vigente; mudança de perfil só entra ao reconectar |
| Numeração fiscal | faixa reservada por estação | usa a faixa própria — é o que evita duas notas com o mesmo número |
| Registro de auditoria | a máquina, com envio garantido | acumula local e sobe inteiro, sem descarte por antiguidade |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
2–3 sem.da classificação à prova rodando
0registros perdidos em queda de conexão
SQLitebanco local sem administração
Documentadotoda decisão com a alternativa descartada
Perguntas frequentes sobre a arquitetura local + nuvem
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Preciso ter servidor na minha empresa?
Muitas vezes não. O padrão que mais usamos é banco local em cada estação conversando direto com a nuvem — sem nenhuma máquina servidora na sua sala, sem sala refrigerada e sem alguém responsável por ela. Servidor local entra quando há volume alto entre estações, quando a rede externa é ruim demais ou quando uma exigência de acesso obriga o dado a não sair do prédio. Nesses casos dizemos no diagnóstico, com o custo de compra e de manutenção na mesa.
Quanto tempo a aplicação aguenta sem internet?
Depende do que combinarmos, e é uma decisão de projeto, não um limite técnico. O banco local aguenta semanas de movimento sem esforço. O que define o prazo aceitável são as regras do negócio: preço desatualizado, estoque sem reconciliar e permissão revogada que ainda não chegou. Definimos com você a partir de quanto tempo o sistema passa a avisar e a partir de quando ele bloqueia certas operações.
Se duas estações alterarem o mesmo registro, qual vence?
A que a regra disser — e a regra é escrita nesta etapa, tipo de registro por tipo de registro. Para movimento, cada estação é dona do que registrou e nada colide. Para cadastro, normalmente a nuvem vence. Para os casos em que escolher errado custa dinheiro, a aplicação não escolhe: ela marca o conflito e apresenta as duas versões para uma pessoa decidir.
E se o computador do caixa queimar com dados não enviados?
É exatamente o risco que a arquitetura precisa tratar antes de acontecer. Por isso a fila tem prazo e alerta: se uma estação passa do tempo combinado sem sincronizar, alguém é avisado enquanto ainda dá para agir. Para operações críticas, replicamos o registro em outra máquina da rede local no mesmo instante da gravação — o custo é pequeno perto de perder um turno inteiro de vendas.
Quer a arquitetura decidida antes do primeiro commit?
Começamos pela classificação dos seus dados e pelo comportamento sem rede. É a etapa que evita o retrabalho mais caro de um projeto desktop.
Continue explorando
As quatro etapas do método e os três recortes da operação — cada uma com o seu próprio detalhamento.
Aplicações DesktopVoltar à visão geral da área
Análise do posto de trabalhoO fluxo real da estação, cronometrado antes de qualquer proposta
Desenvolvimento e integraçãoA aplicação conversando com balança, impressora fiscal, coletor e PDV de verdade
Instalação e atualizaçãoInstalador assinado e versão nova em todos os postos sem visitar máquina por máquina
Aplicação em operaçãoVárias janelas, processamento pesado e o turno inteiro sem reiniciar
Estação de trabalhoA tela desenhada para o uso intenso: densidade, foco e caminho curto
Ambiente de Aplicações DesktopAs camadas que sustentam o parque, do driver do periférico à nuvem