Um usuário exclui um registro em um aplicativo e, horas depois, encontra-o novamente porque outro aplicativo o sincronizou. Em geral, não se trata de um problema de «exclusão» isolado: há uma divergência entre sistemas sobre qual ação ocorreu, o que ela significa e quem deve respeitá-la. Para resolver essa situação, é preciso acordar regras de negócio e de integração antes de conectar os aplicativos.
A questão prática não é apenas como sincronizar exclusões entre sistemas. Também é preciso decidir se o registro deve desaparecer, ficar oculto, ser mantido para auditoria ou continuar disponível para processos pendentes. Este artigo diferencia essas decisões e apresenta critérios para transmiti-las, evitar restaurações involuntárias e lidar com exceções.
Por que uma exclusão local nem sempre chega aos sistemas conectados
Uma integração pode copiar inclusões e alterações sem transmitir exclusões. Por exemplo, se ela consulta periodicamente os registros disponíveis e envia apenas aqueles que encontra, um registro que já não aparece na origem não gera necessariamente uma mensagem para o destino. Para o sistema receptor, essa ausência pode significar que ele nunca recebeu o registro, que a consulta falhou ou que o registro foi excluído. Sem uma regra explícita, não é possível saber qual dessas situações ocorreu.
O problema também acontece quando um aplicativo mantém o registro e outro o exclui permanentemente. Se uma sincronização posterior publicar novamente o registro mantido, o destino poderá recriá-lo. Uma lógica baseada na «última atualização» também pode não ser suficiente: a exclusão talvez não tenha uma marca de tempo nem uma versão que permita compará-la às alterações recebidas.
Antes de projetar a solução, identifiquem quais aplicativos podem criar, editar ou retirar o registro, qual deles tem autoridade sobre cada dado e o que significa deixar de disponibilizá-lo. Em uma sincronização bidirecional, também é preciso decidir o que acontece se um aplicativo excluir o registro enquanto outro o altera. Sem essa decisão, o sistema não consegue resolver o conflito de maneira confiável.
Excluir, arquivar e desativar são ações diferentes
- Exclusão permanente: o registro é removido da estrutura ativa do sistema. Ele pode deixar de estar acessível pelas funções habituais, embora cópias de segurança, registros técnicos ou políticas de retenção possam seguir regras próprias. Não escolham essa opção supondo que ela apaga automaticamente todos os vestígios.
- Arquivamento: o registro é mantido, mas retirado das atividades cotidianas, por exemplo, das visualizações padrão. Isso é útil quando é necessário consultar o histórico ou preservar o contexto. É preciso definir se os sistemas conectados recebem o estado «arquivado» ou se simplesmente deixam de exibi-lo.
- Desativação: o registro permanece, mas deixa de participar de uma operação. Um produto desativado pode continuar associado a pedidos anteriores, embora não seja oferecido em novas vendas. A condição exata depende do processo: «inativo» não tem um significado universal.
Também convém diferenciar uma remoção solicitada de uma correção. Se um usuário excluiu um registro por engano, restaurá-lo pode ser adequado; se a remoção é definitiva, restaurá-lo por meio da sincronização é uma falha. Modelem essas ações separadamente quando elas provocarem diferenças em permissões, retenção ou efeitos operacionais.
Escolher o significado de acordo com o processo de negócio
Comecem pela consequência observável, não pela função disponível na interface. Perguntem o que cada equipe e sistema deverá poder fazer depois da ação. Será possível iniciar uma nova operação com esse registro? Ele deverá continuar aparecendo em pesquisas históricas? Há faturas, pedidos, casos ou relatórios que dependem dele? As respostas podem levar a decisões diferentes para cada tipo de registro.
Uma regra prática é usar a desativação quando o registro ainda for válido como referência, mas não puder iniciar novas operações; o arquivamento quando for necessário mantê-lo e retirá-lo da atividade normal; e a exclusão permanente somente quando a política aplicável e as dependências permitirem removê-lo. Essa não é uma hierarquia obrigatória: a decisão deve considerar as necessidades do negócio, os requisitos de retenção e os recursos reais dos sistemas.
Documentem a regra em termos verificáveis. Em vez de «ao excluir, sincronizar a remoção», especifiquem qual ação a inicia, quais sistemas a recebem, o que muda em cada um e se a ação pode ser revertida. Definam também a autoridade: se apenas um sistema pode decidir pela remoção, alterações em outros sistemas não devem reativar o registro sem uma ação autorizada.
Qual sinal deve ser transmitido pela integração
A integração precisa de uma representação inequívoca. Uma opção é transmitir um evento de remoção quando a ação acontece. Outra é enviar um estado explícito, como ativo, arquivado ou desativado, em cada troca relevante. Também é possível usar uma marca de exclusão — por exemplo, um indicador de remoção — que mantenha o registro e permita reconhecê-lo em sincronizações futuras.
A escolha depende do funcionamento da troca de dados. Os eventos permitem comunicar a alteração quando ela ocorre, mas os sistemas precisam lidar com novas tentativas, duplicidades e mensagens fora de ordem. Um estado explícito facilita a comparação do estado atual, mas exige que as consultas incluam registros inativos ou suas marcas de remoção. Se a origem simplesmente omitir um registro excluído, o receptor não terá informações suficientes para distinguir uma remoção de uma ausência temporária.
Seja qual for o mecanismo, definam um identificador estável para relacionar o registro entre sistemas, o estado ou tipo de ação, o momento ou a versão da alteração e o sistema de origem. O receptor deve conseguir processar o mesmo sinal mais de uma vez sem produzir efeitos contraditórios. Se os aplicativos tiverem estados diferentes, estabeleçam uma correspondência explícita; não suponham que «arquivado» em um deles equivale a «excluído» em outro.
Como evitar que uma sincronização restaure registros
A principal proteção é manter e propagar a informação de remoção por tempo suficiente para que os demais sistemas a recebam. Se o registro for excluído permanentemente na origem antes que a integração o detecte, a única evidência de que ele existia também poderá desaparecer. Uma marca de remoção ou um registro de evento mantido até a confirmação da propagação evita depender dessa ausência.
O destino deve reconhecer a remoção como um estado, e não como uma instrução passageira que desaparece após o processamento. Se receber depois uma cópia antiga marcada como ativa, precisará de uma regra de precedência: por exemplo, comparar a versão ou o momento da alteração e rejeitar os dados mais antigos. Em processos nos quais a restauração seja permitida, exijam uma ação de reativação explícita e autorizada, em vez de deduzi-la de uma atualização comum.
Prevejam também a recuperação após interrupções. Uma sincronização retomada deve conseguir detectar alterações ocorridas enquanto esteve parada. Definam como os sinais serão reenviados, como identificar mensagens já aplicadas e como revisar erros. Um relatório de remoções pendentes e alertas sobre registros recriados ajudam a detectar o problema antes que ele se transforme em uma divergência difícil de rastrear.
Referências, processos pendentes e exceções
Um registro pode estar relacionado a outros dados que precisam ser mantidos: um pedido, uma transação, um caso de atendimento ou um histórico de alterações. Excluí-lo permanentemente pode quebrar uma referência ou dificultar a interpretação de uma operação passada. Nesses casos, o sistema receptor talvez precise manter uma versão mínima ou marcar o registro como indisponível para novas operações. A decisão deve respeitar as políticas aplicáveis e os recursos de cada sistema, sem presumir que todos aceitam o mesmo tipo de remoção.
Avaliem separadamente os registros que estão em processo. Se uma solicitação já foi aprovada, um produto incluído em um pedido ou uma tarefa em andamento for desativada, ela será cancelada, concluída ou mantida sem novas operações? Uma regra geral pode não ser suficiente: definam qual processo prevalece e quem pode resolver a exceção. Se um aplicativo não aceitar exclusões, atribuam a ele um estado de remoção compatível e documentem quais dados serão mantidos e quem poderá consultá-los.
As correções exigem outro fluxo. Uma remoção equivocada pode exigir a restauração, mas reativar um registro não deve apagar o histórico da remoção nem ocultar quem tomou a decisão. Separar «corrigir uma remoção», «restaurar» e «reativar» ajuda a manter uma auditoria compreensível e evita que um processo automático reabra registros por acidente.
Lista de verificação antes do lançamento
- Definam o escopo: identifiquem os tipos de registro, os sistemas participantes e as ações que podem iniciar uma remoção.
- Alinhem os significados: especifiquem o que excluir, arquivar e desativar implica para cada processo de negócio.
- Atribuam a autoridade: estabeleçam quem pode remover e quem pode restaurar ou reativar.
- Projetem o sinal: escolham entre evento, estado ou marca de remoção e definam identificadores, versões e tratamento de duplicidades.
- Protejam as dependências: verifiquem referências, histórico, processos pendentes e sistemas que não permitem exclusões.
- Testem cenários adversos: incluam mensagens repetidas, sincronização interrompida, alterações simultâneas, dados antigos e restaurações autorizadas.
- Preparem o acompanhamento: definam como revisar remoções pendentes, falhas, recriações e divergências, e quem deve agir diante de cada alerta.
A decisão acertada nem sempre é excluir. O importante é transmitir uma intenção de negócio clara, manter as informações necessárias e fazer com que todos os sistemas conectados a interpretem de maneira coerente. Quando a regra pode ser expressa em estados, responsáveis, exceções e testes observáveis, é muito menos provável que uma sincronização transforme uma remoção em uma inclusão inesperada.