SENAC

Visão Geral

Atuei no SENAC AL em um cenário em que múltiplas unidades dependiam de um sistema centralizado para operações de atendimento, cadastro e venda de cursos. O ambiente apresentava conectividade instável entre unidades, o que fazia o atendimento parar sempre que o vínculo com a base central caía.

O desafio foi redesenhar a lógica operacional para permitir continuidade do serviço mesmo em condições precárias de rede, reduzindo a dependência de conexão permanente com o banco central e distribuindo melhor a carga entre serviços.

Contexto

Experiência prévia com sistemas de alta concorrência e tolerância a falhas (inspirada em servidores de jogos online). Problema concreto no SENAC: cadastro de alunos, venda de cursos, rotinas administrativas, atendimento ao público; falha de conectividade parava ou comprometia operações.

Problema Técnico

Limitações estruturais e dependência excessiva de centralização.

Condições do ambiente:

• múltiplas unidades distribuídas
• comunicação instável entre unidades e serviços centrais
• forte dependência de banco de dados central
• acoplamento elevado entre operação local e disponibilidade da rede

Consequências práticas:

• interrupção do atendimento
• impossibilidade de concluir vendas e cadastros
• perda de produtividade
• risco operacional em períodos de instabilidade

Objetivo da Solução

O objetivo não era apenas melhorar desempenho. Era permitir que a operação continuasse funcionando mesmo diante de falhas de conectividade, com posterior sincronização dos dados e menor pressão sobre o banco central.

Em termos arquiteturais, a meta era:

• sustentar operação local mesmo com falha de comunicação
• reduzir dependência síncrona da base central
• distribuir carga entre múltiplos serviços
• preservar consistência operacional com sincronização posterior

Meu Papel

• análise do problema e concepção da abordagem
• implementação da solução em Delphi
• aplicar distribuição de carga, separação de serviços e operação resiliente
• posteriormente: gestão de TI, infra, coordenação operacional

Arquitetura Proposta

1. Cache inteligente no cliente — estações mantinham catálogo de cursos e dados essenciais para continuar operando offline
2. Sincronização assíncrona — operações locais sincronizadas após retorno da conectividade
3. Redução da carga sobre o banco central — cache intermediário, controle de sincronização, organização de requisições
4. Distribuição de carga — múltiplos IPs/serviços conectados à mesma base, distribuição dinâmica
5. Arquitetura inspirada em servidores distribuídos — cliente → serviços intermediários → base central, com divisão de responsabilidades e isolamento parcial de falhas

Fluxo Operacional Simplificado

1. atendimento com dados locais
2. operações continuam mesmo na instabilidade
3. eventos pendentes aguardam conectividade
4. sincronização posterior
5. reconciliação e persistência na base central

Resultados Alcançados

• continuidade de vendas e cadastros mesmo sem conexão ativa em determinados momentos
• sincronização posterior das operações realizadas localmente
• manutenção do atendimento ao público em cenários de instabilidade
• melhor suporte ao funcionamento simultâneo de múltiplas unidades
• abertura para cenários operacionais mais flexíveis (vendedores em campo, treinamentos em localidades com infraestrutura limitada)

Relevância Técnica

• arquitetura offline-first
• sincronização eventual
• tolerância a falhas
• distribuição de carga
• redução de acoplamento operacional
• adaptação de princípios a ambiente corporativo com limitações

Aprendizados

• conectividade não pode ser premissa rígida quando a operação depende de continuidade
• arquitetura precisa refletir o ambiente real, não o ambiente ideal
• separar serviços e distribuir carga aumenta a resiliência do sistema
• operação local com sincronização posterior pode ser mais adequada do que bloqueio síncrono
• referências vindas de contextos não tradicionais também podem gerar soluções corporativas valiosas

Resumo Curto

Analista Sênior / Gerente de TI — solução distribuída em Delphi com cache local, sincronização assíncrona e múltiplos serviços/IPs conectados à mesma base, permitindo operação offline-first e distribuição de carga em ambiente com links instáveis.

Sugestão de Uso

Referência: https://carlosrosset.com.br/cases/senac/offline-architecture