Se há uma pergunta técnica que eu faço ao avaliar uma equipe móvel, é sobre como eles lidam com o estado offline e resolução de conflitos.
Não porque cada aplicativo precisa do suporte offline. A maioria não precisa, pelo menos não totalmente. Faço essa pergunta porque a resposta quase impossível de ser falsificada e porque mapeia diretamente para se uma equipe já operou apps no mundo real ou apenas os construiu em um escritório com boa conexão Wi-Fi.
Por que esta pergunta funciona
O offline é onde o móvel deixa de ser um cliente fino e torna-se um sistema distribuído.
No momento em que um dispositivo pode aceitar uma escrita que não pode enviar imediatamente, você tem duas cópias da verdade e um problema de fusão. Tudo o que é desagradável sobre sistemas distribuídos chega ao mesmo tempo — ordem, idempotência, falha parcial, desajuste no relógio e uma interface do usuário que precisa representar incerteza sem confundir ninguém.
Você não pode raciocinar sua forma a partir de princípios fundamentais em uma entrevista. Ou uma equipe passou por isso ou não.
O que as respostas parecem
"Nosso aplicativo requer conectividade."
Por vezes legítimo. Frequentemente significa que a pergunta ainda não foi considerada, e o app irá se comportar mal na estação subterrânea, em um elevador, no porão de um hospital ou em um trem através dos Cotswolds.
Siga com: o que acontece se a rede cair durante uma submissão? Se a resposta for um spinner que nunca resolve, ou um registro duplicado quando o usuário tenta novamente, você tem sua resposta.
"Usamos last-write-wins."
Uma estratégia real e defensável para dados genuinamente de único usuário — configurações, rascunhos, preferências pessoais. Perda silenciosa de dados para qualquer coisa colaborativa.
Siga com: o que acontece se dois dispositivos pertencentes ao mesmo usuário editarem o mesmo registro? Uma equipe que lançou saberá imediatamente se esse caso existe em seu app e o que acontece.
"Nós enfileiramos mutações e as retransmitimos."
Agora estamos em algum lugar. As perguntas importantes:
- São as mutações idempotentes, e como isso é garantido? IDs geradas pelo cliente é a resposta usual.
- O que acontece quando uma mutação retransmitida falha na validação porque o estado do servidor mudou? É descartada, tentada para sempre ou levantada para o usuário?
- A ordem é preservada em operações dependentes — criar-então-atualizar no mesmo entidade?
- Quanto grande a fila pode ficar e o que acontece quando excede isso?
Uma equipe que executou isso em produção responde rapidamente e menciona pelo menos uma coisa que erraram na primeira vez.
"Usamos CRDTs."
Por vezes exatamente certo, particularmente para texto ou estruturas de lista colaborativas. Pode ser uma resposta impressionante a um problema que uma fila de mutações resolveria em um quinto do tempo.
Siga com: qual CRDT, para qual dado e qual é o perfil de memória em um dispositivo Android de baixo custo após um ano de histórico? A última parte é onde as respostas reais vivem.
As partes que todo mundo subestima
Tres especificidades que separam uma implementação funcional daquela que funciona parcialmente.
Incerteza no relógio. Os relógios dos dispositivos estão errados, às vezes muito, e os usuários alteram. Qualquer estratégia de conflito que dependa de timestamps do dispositivo para ordem está quebrada de uma maneira que não aparecerá até que aconteça. Números sequenciais atribuídos pelo servidor ou relógios lógicos são as respostas viáveis.
Migração de esquema com fila em trânsito. Você lança um update. Alguns usuários têm mutações pendentes enfileiradas na forma antiga. Essas mutações ainda precisam ser aplicadas. Isso é genuinamente difícil e é a origem de algumas das piores falhas de dados que já vi — equipes que atingiram uma vez nunca esquecem.
Representando incerteza na UI. O estado não está "salvo" ou "não salvo" — está "aceito localmente, ainda não confirmado, possivelmente prestes a ser rejeitado." A maioria dos apps simplifica isso em uma marca de verificação e confunde o usuário mais tarde quando algo muda silenciosamente. Equipes com experiência em produção têm opiniões sobre isso, geralmente fortes.
The AI wrinkle
Newer and increasingly common: se o aplicativo tem recursos de IA, a história offline ganha uma segunda dimensão.
A inferência geralmente requer conectividade, o que significa que um recurso de IA é um recurso online a menos que você tenha enviado um modelo em dispositivo. Isso tem consequências para como você apresenta a disponibilidade — um recurso que se deteriora silenciosamente é pior do que aquele que claramente afirma precisar de uma conexão.
Também há uma questão de filas. Se o usuário desencadeia uma ação de IA offline, você enfileira o pedido? Se os dados subjacentes tiverem mudado quando ele é executado, o resultado ainda faz sentido? Geralmente não, o que argumenta por falhar rapidamente em vez de enfileirar — mas é uma decisão e deve ser consciente.
Por que isso se generaliza
A razão pela qual me apoio tanto nesta pergunta é que ela serve como um proxy. Uma equipe com uma resposta considerada sobre sincronização offline quase sempre tem respostas consideradas nos outros aspectos que importam — processamento em segundo plano, confiabilidade de push, estratégia de migração, triagem de falhas, o que acontece quando a loja rejeita um envio.
A experiência de produção é uma única característica que aparece em todos os lugares. A sincronização offline é apenas o lugar mais barato para testar isso.
O guia mais amplo para avaliar as empresas de aplicativos móveis do Reino Unido — faixas de custo de 2026, arquétipos de agências, requisitos de conformidade e termos contratuais — está aqui, e nosso trabalho em desenvolvimento de aplicativos móveis aborda o lado da arquitetura com mais profundidade.
Perguntas frequentes
Todos os aplicativos móveis precisam de suporte offline?
Não, e construir uma capacidade completa offline em um aplicativo que não precisa dela é um erro comum e caro. Mas cada aplicativo precisa de uma resposta considerada para o que acontece quando a rede cai no meio da operação — mesmo que essa resposta seja um estado de erro claro e uma retentativa segura em vez de um motor de sincronização.
Last-write-wins é aceitável em algum momento?
Para dados genuinamente de um único usuário e dispositivo, como configurações, rascunhos e preferências, sim. Para qualquer coisa colaborativa ou algo que o usuário possa tocar de dois dispositivos, produz perda silenciosa de dados. O teste é se o mesmo registro pode ser editado em duas localizações; se puder, last-write-wins acabará por destruir algo.
Pelo que o desacordo de horário é um problema tão grande para sincronização?
Porque os relógios dos dispositivos estão frequentemente errados e os usuários podem alterá-los. Qualquer estratégia de resolução de conflitos que ordene operações por marcação de tempo do dispositivo produzirá fusões incorretas de maneiras extremamente difíceis de reproduzir. Números sequenciais atribuídos pelo servidor ou relógios lógicos evitam toda a classe de bug.
O que acontece com mutações enfileiradas quando eu envio uma alteração de esquema?
Eles ainda precisam ser aplicados, na sua forma antiga, após a atualização. Isso é um dos problemas mais difíceis da sincronização offline e uma fonte comum de corrupção de dados séria. Lidar com isso geralmente significa versionar mutações enfileiradas e manter caminhos de migração para itens em trânsito — equipes que já enfrentaram isso projetam para lidar com isso no futuro.
Como os recursos de IA devem se comportar offline?
Geralmente falhando rapidamente e dizendo isso, em vez de enfileirar. A inferência geralmente precisa de conectividade, e uma solicitação de AI enfileirada pode produzir um resultado sem sentido se os dados subjacentes mudaram antes que ela fosse executada. Um recurso que claramente afirma precisar de conexão é melhor do que aquele que silenciosamente se deteriora.