A conexão existia, mas não podia ser tratada como certa
Treinar uma equipe embarcada parecia, de início, um caso comum de acesso remoto ao Software Moodle™, até colocarmos na mesa o custo do satélite, a latência, as áreas sem cobertura, a duração das viagens e a quantidade de pessoas dividindo a mesma conexão, pois uma página que abria em poucos segundos no escritório podia chegar incompleta no navio, um vídeo interrompido recomeçava do início e uma avaliação enviada no instante de uma queda deixava o aluno sem saber se a resposta havia sido gravada, então antes de propor qualquer arquitetura acompanhamos diferentes períodos de navegação, medimos tempos de resposta, registramos interrupções e conversamos com quem estudava a bordo para entender em que horários a conexão melhorava e quais atividades eram abandonadas primeiro quando o acesso ficava instável.
Os testes com limitação artificial de banda ajudaram, mas não reproduziram toda a realidade, porque o problema não era somente velocidade baixa, havia perda de pacotes, mudanças bruscas de latência, intervalos longos sem qualquer comunicação e reconexões que duravam poucos minutos, suficientes para iniciar uma transferência e curtas demais para concluí la, por isso repetimos login, abertura de curso, reprodução de mídia, tentativa de questionário e envio de arquivo em vários cenários, desligando a rede em momentos diferentes e observando quais ações se recuperavam sozinhas, quais ficavam em estado indefinido e quais poderiam duplicar informações quando o usuário tentava novamente.
A conclusão foi direta, o estudo precisava acontecer em uma instalação local dentro de cada embarcação, com páginas e mídias disponíveis na rede interna e resposta imediata para os alunos, enquanto uma plataforma central em terra cuidaria da distribuição dos cursos e da consolidação dos resultados, decisão que transferia a complexidade da sala de aula para a sincronização, um lugar mais adequado porque uma fila pode esperar pela próxima janela de conexão, mas um estudante diante de uma avaliação não deveria depender da qualidade do satélite naquele minuto.
Dois ambientes sem duas verdades
Ter uma plataforma no navio e outra em terra criava uma pergunta difícil, qual delas seria a fonte correta quando uma matrícula mudasse, um curso fosse atualizado e uma tentativa já estivesse acontecendo a bordo, então definimos a responsabilidade de cada informação antes de escrever o mecanismo de transferência, deixando matrículas, versões de cursos e regras de oferta sob controle da central, enquanto tentativas, notas, conclusões e registros produzidos durante a viagem nasciam no ambiente local e seguiam para consolidação, com exceções tratadas explicitamente para que uma alteração feita em terra não apagasse o que já havia sido realizado no navio.
Cada evento recebeu um identificador único criado na origem, juntamente com horário local, referência de usuário, curso, atividade, versão do conteúdo e situação da transmissão, assim o mesmo pacote poderia ser enviado várias vezes sem gerar duas tentativas ou duplicar uma conclusão, pois a central verificava se o identificador já havia sido aplicado e respondia com uma confirmação que permitia à embarcação encerrar aquele item da fila, enquanto eventos incompletos permaneciam disponíveis para nova tentativa, um detalhe essencial em conexões nas quais perder a resposta não significa necessariamente que o servidor deixou de receber os dados.
Também evitamos depender de uma sequência contínua, porque um pacote menor poderia chegar antes de outro mais antigo e ainda assim precisávamos preservar a ordem real das ações, então a consolidação usava identificadores, horários, dependências e versões para decidir quando aplicar cada mudança, guardando temporariamente o evento que dependia de um dado ainda ausente e produzindo um relatório claro de pendências, em vez de parar toda a sincronização por causa de um único registro problemático.
Fazer caber na próxima janela de comunicação
Os cursos precisavam chegar às embarcações sem consumir toda a conexão, por isso deixamos de pensar em um grande pacote enviado a cada atualização e passamos a identificar exatamente o que havia mudado, separando metadados, atividades, documentos e mídias, enquanto os vídeos recebiam versões adequadas às telas disponíveis e eram divididos em blocos verificáveis, dessa forma uma interrupção não exigia começar novamente e o sistema podia continuar pelo último bloco confirmado, com prioridade para correções pequenas e conteúdos obrigatórios antes de materiais complementares muito maiores.
A fila considerava tamanho, urgência, dependências e qualidade momentânea da conexão, enviando primeiro os resultados acumulados pelos alunos, depois as correções que impediam o acesso a uma atividade e somente então as mídias mais pesadas, além disso cada bloco levava hash e posição dentro do arquivo, permitindo detectar uma transferência corrompida sem descartar tudo, enquanto o destino montava o conteúdo em uma área temporária e só substituía a versão em uso quando o pacote inteiro estivesse confirmado, evitando que um curso ficasse pela metade para quem já estava estudando.
Nos ensaios nós elevamos a latência, descartamos pacotes, cortamos a conexão por horas e forçamos várias reconexões seguidas, observando o tamanho das filas, o tempo para recuperar o atraso e o efeito de uma atualização grande sobre os resultados pedagógicos, depois levamos um piloto para uma embarcação e comparamos as medições do laboratório com o uso real, ajustando o intervalo das tentativas, o volume de cada bloco e os horários preferenciais para não disputar banda com comunicações operacionais mais importantes.
Os problemas que só aparecem durante uma viagem longa
Quando a primeira embarcação voltou a uma conexão melhor, a plataforma enviou dias de atividades acumuladas e recebeu apenas os conteúdos alterados, porém a consolidação revelou que horário do navio, horário da central e horário registrado por alguns equipamentos não estavam alinhados, fazendo prazos parecerem vencidos e conclusões chegarem fora de ordem, então mudamos o modelo para preservar o momento informado pela origem junto com a referência de fuso e a sequência local, deixando o horário de recebimento apenas como dado de auditoria, correção que parece pequena mas foi decisiva para que relatórios e certificados contassem a história verdadeira do aluno.
Também encontramos arquivos que permaneciam incompletos depois de muitas tentativas, eventos retidos por uma dependência que nunca chegava e conflitos causados por mudanças feitas em terra durante uma viagem, por isso criamos painéis voltados à operação da fila, mostrando o último contato de cada embarcação, o volume pendente, os itens repetidamente recusados e a versão dos cursos, junto com ações seguras para reenviar um pacote, ignorar uma alteração comprovadamente inválida ou solicitar uma nova cópia da informação ausente, sem permitir que a equipe resolvesse um conflito apagando registros no banco por tentativa e erro.
A estabilização aconteceu quando a sincronização deixou de ser vista como uma cópia de arquivos e passou a ser tratada como uma troca de eventos entre ambientes que podiam permanecer separados por muito tempo, com confirmação, retomada, prioridade, histórico e regras claras sobre quem podia alterar cada dado, o que tornou possível estudar a bordo com resposta local e, ao mesmo tempo, manter em terra uma visão confiável da formação realizada durante a viagem.
O oceano não precisava desaparecer para o projeto funcionar, era o sistema que precisava aceitar a distância, aproveitar cada oportunidade de comunicação e nunca obrigar o aluno a repetir uma atividade apenas porque a conexão terminou antes da confirmação.