Por Que o QuickBooks Não Pode Ser Armazenado no Google Drive para Múltiplos Usuários

Antes de entrarmos em detalhes específicos, é importante entender que se trata de um conceito geral e que podemos, na verdade, reduzi-lo a “por que aplicativos cliente/servidor ou de arquivo de banco de dados compartilhado não podem ser armazenados em armazenamento sincronizado (por exemplo, Google Drive, DropBox, NextCloud, etc.) quando o acesso não é controlado para um único usuário?” O QuickBooks utiliza um mecanismo de arquivo de banco de dados compartilhado, comum a aplicativos no estilo dos anos 1980, no qual um único arquivo ou conjunto de arquivos é compartilhado por meio de um mecanismo de compartilhamento de arquivos e cada cópia individual do aplicativo acessa esse arquivo para modificá-lo. O Google Drive é um mecanismo de armazenamento sincronizado: ou seja, ele faz cópias dos dados de um local para outro. Pessoas trabalhando no mesmo arquivo ao mesmo tempo podem, e frequentemente o fazem, sobrescrever as alterações umas das outras, e a expectativa é que essas alterações sejam reconciliadas manualmente mais tarde, ignoradas, ou que os usuários sejam controlados para impedir que trabalhem ao mesmo tempo.

Para alguns tipos de aplicativos multiusuário, o armazenamento sincronizado pode ser aproveitado, mas apenas em situações em que o aplicativo é capaz de ser bloqueado pelo sistema de armazenamento para permitir alterações somente quando nenhuma outra existir. Isso requer um nível de integração que não é prático com a sincronização de arquivos de uso geral. A maioria dos sistemas que fazem isso utiliza um mecanismo de sincronização incorporado à camada de banco de dados ou de aplicativo, e não um de uso geral que precisa funcionar às cegas. Para que a integridade dos dados seja mantida com armazenamento sincronizado, é necessário que apenas uma pessoa edite um arquivo por vez, aguarde que todos os potenciais usuários recebam as atualizações feitas após o “salvamento” desse arquivo, e então um usuário diferente possa editar esse arquivo e repetir o processo. Mas apenas um usuário por vez pode trabalhar no arquivo e deve receber as atualizações do outro usuário antes de abrir o arquivo para editá-lo. Caso contrário, o sistema precisa perguntar aos usuários, em cada caso, quais alterações manter e quais descartar.

Esse processo de integridade não pode ser aplicado a um arquivo de banco de dados de forma alguma realista. O arquivo é projetado para permanecer aberto e ser acessado o tempo todo, e não apenas para ser aberto, editado e salvo rapidamente. O salvamento também não é manual, nem sempre previsível. Geralmente presumimos que o salvamento ocorre continuamente durante o uso, mas o cache pode tornar até mesmo essas operações de salvamento impossíveis de controlar manualmente. Mas isso é necessário por razões de desempenho.

A confusão muitas vezes surge porque um único usuário, sem o receio de que outro usuário acesse o sistema ao mesmo tempo, pode usar armazenamento sincronizado, como o Google Drive ou o Apple iCloud, para atuar como mecanismo de backup (ele simplesmente faz uma cópia remota automaticamente) e/ou como meio de replicar o arquivo para que o usuário único possa usá-lo primeiro de um local e depois de outro, sem precisar mover manualmente o arquivo de um lugar para outro. Desde que esse usuário único leve tempo suficiente ao se deslocar entre os locais para garantir que qualquer cache tenha sido esvaziado e que as sincronizações e os bloqueios tenham sido concluídos, ou garanta que não deixou a primeira instância do aplicativo aberta, ele pode razoavelmente presumir que tem um sistema seguro (mas não pode garanti-lo por completo — o mecanismo carrega um risco mínimo de condições de corrida mesmo assim). Como existe “uma maneira” de usar com segurança o armazenamento sincronizado com o aplicativo em modo de usuário único, muitos profissionais de contabilidade ou finanças sem formação técnica presumem incorretamente que o acesso simultâneo multiusuário, que é algo totalmente diferente, também funcionará. Isso, no entanto, não é possível.

O que acontece é que se cria uma condição de corrida entre múltiplos usuários e nunca é possível ter total certeza de que ela não ocorreu. Às vezes, os dados simplesmente ficarão incorretos e não haverá dúvida de que uma condição de corrida ocorreu, pois os números estarão absurdamente imprecisos. Mas, com mais frequência, algumas transações simplesmente serão perdidas mesmo depois de terem sido revisadas.

Vamos dar um exemplo. O Usuário 1 está em casa e insere um novo recibo no QuickBooks. Essa alteração começa a ser salva no computador local e, depois que isso é concluído, o aplicativo começa a encaminhar o novo arquivo para o Google Drive na nuvem (online). O Usuário 2 está no escritório e começa a registrar o pagamento de um cliente em uma fatura durante esse período. A cópia do arquivo de dados do QuickBooks do Usuário 2 está aberta e não pode ser sobrescrita enquanto está em uso, de modo que a cópia que está sendo enviada ao Google Drive não consegue chegar ao Usuário 2. Assim que o Usuário 2 salva sua alteração, sua cópia também quer ser enviada ao Google Drive. Agora o Google Drive precisa fazer algo com dois documentos que começaram idênticos, mas que agora têm duas alterações radicalmente diferentes, sendo que nenhuma das cópias contém ambas. Ele não tem como mesclá-las, então pode aceitar o Usuário 1 como mestre e descartar as alterações do Usuário 2 (por exemplo, prioridade ao primeiro). Ou pode aceitar as alterações do Usuário 2 e descartar as alterações do Usuário 1 (por exemplo, prioridade ao mais recente). Ou, é claro, pode descartar todas as alterações e não aceitar nenhuma. Em nenhum dos casos todas as transações financeiras dos usuários são preservadas, mesmo depois de terem sido salvas localmente. Tanto o Usuário 1 quanto o Usuário 2 (ou possivelmente ambos) terão dados que acreditavam ter salvado de repente desaparecendo. Acrescente mais usuários, e o problema só fica maior.

Parte do problema é que, ao trabalhar em nível de acesso a arquivos e sincronizar e compartilhar dados em nível de arquivo completo, não há como bloquear apenas um registro ou linha, ou manter as transações separadas, ou mesclar alterações. O arquivo é uma entidade única e ele mudou. É tudo ou nada. Os aplicativos individuais do QuickBooks não conseguem se comunicar diretamente entre si, nem por meio do arquivo de banco de dados, para coordenar gravações, salvamentos, leituras, etc. de modo a contornar esse problema. Eles estão cegos e não têm como saber que outros aplicativos estão tentando trabalhar com o arquivo ao mesmo tempo, porque cada um possui sua própria cópia exclusiva do arquivo; não há nada “compartilhado” entre eles que permita a comunicação. As cópias não estão vinculadas umas às outras; não há nenhum estado quântico envolvido aqui. E então podemos acrescentar os possíveis problemas de uma ou mais instâncias do aplicativo serem usadas quando há uma conexão de Internet lenta ou com falhas ou, pior, quando uma instância está offline. Pode haver horas ou dias de alterações que precisam sobrescrever, ou ser sobrescritas, quando a sincronização finalmente ocorre. Raramente estamos falando de milissegundos, mas frequentemente de dias de dados.

A forma como esse problema é tratado, quando é tratado, por arquivos compartilhados localmente é multifacetada. Primeiro, existe apenas um arquivo, e não cópias desse arquivo. Assim, todas as alterações ficam disponíveis para todas as cópias do aplicativo de forma simultânea e instantânea. Quando uma instância do aplicativo vai gravar dados no arquivo, ela usa um mecanismo de bloqueio e alerta semelhante ao modo como os Sistemas de Arquivos em Cluster permitem que as SANs funcionem, no qual pode sinalizar às outras instâncias do aplicativo que uma alteração está sendo feita e que elas precisam esperar que ela seja concluída, e então atualizar sua cópia dos dados antes de prosseguir. Apenas uma instância pode gravar e todas as outras precisam esperar. Não há condições de corrida porque o bloqueio é obtido antes de começar e liberado quando concluído. E todas as instâncias só funcionam enquanto os dados estiverem atualmente acessíveis; se a conexão for perdida, elas ficam impossibilitadas de prosseguir. Um mecanismo crítico de proteção da integridade dos dados. Alguns aplicativos levam esse mecanismo a um nível ainda maior e adicionam canais de comunicação diretos (em vez de por meio do arquivo compartilhado) para tornar esse processo mais rápido e obter melhor desempenho. Mas poucos vão tão longe, pois, uma vez que se chega a esse nível, geralmente é muito mais fácil simplesmente migrar para um aplicativo moderno do que tentar encaixar sistemas multiusuário modernos em designs com décadas de existência.

Esperamos que isso tenha esclarecido por que os contadores comumente pensam que arquivos sincronizados funcionarão e por que frequentemente afirmam que “funcionou para mim” quando deveriam dizer “tive sorte” ou “usei em um cenário totalmente diferente, que não se aplica a um ambiente multiusuário”, e por que você pode absolutamente usar o Google Drive, NextCloud, iCloud, DropBox e outros com o QuickBooks e outros aplicativos de estilo legado para backups e transferências de dados, mas não pode cogitar tentar usá-los como meio de obter acesso multiusuário, pois eles simplesmente não conseguem manter os dados intactos.