FCOPTS — Francisco Pontes
InícioSobreProjetosContatoBlog
Peça um orçamentoNovo
  • 01Sobre
  • 02Projetos
  • 03Contato
  • 04Blog
Peça um orçamentoNovo
Estudo de Caso

SDA Ceará: Modernizando a Gestão Agrária do Estado

App + Sistema Web/Admin para a Secretaria do Desenvolvimento Agrário

Aplicativo oficial do Governo do Ceará que centraliza os sistemas da Secretaria do Desenvolvimento Agrário (SDA): indicadores de demandas e ações, chamados técnicos, agenda, mensageria e questionários, unificando módulos que antes operavam isolados.

React NativeReact Native
PostgreSQLPostgreSQL
.NET.NET
C#C#
PHPPHP
DockerDocker
KubernetesKubernetes
GrafanaGrafana
PrometheusPrometheus
SDA Ceará · app mobile
Tipo de projetoApp Mobile
Papel exercidoDesenvolvedor Mobile
IdealizadorGoverno do Ceará / SDA
StatusEm produção
Duração1,8 anos de evolução contínua
ObjetivoRefatoração + novos módulos

O SDA Ceará representa a modernização, módulo por módulo e sem downtime, de um sistema de governo já em uso, unificando indicadores, chamados, agenda e questionários em um único app para os servidores da Secretaria do Desenvolvimento Agrário.

Contexto e Escopo

O SDA Ceará é o aplicativo oficial da Secretaria do Desenvolvimento Agrário do Governo do Ceará, usado por servidores para acompanhar indicadores de demandas e ações (sistema IDA), abrir e controlar chamados técnicos, gerenciar agenda e mensagens, e responder questionários. O app também dá visibilidade a programas vinculados, como o Ceará Sem Fome e o Projeto São José.

Módulos centralizados no app

  • Indicadores de Demandas e Ações (IDA), com relatórios e dashboard
  • Chamados técnicos e burocráticos via Sistema de Atividades
  • Agenda, mensageria com histórico e questionários (SDA)
  • Filtros cruzados por entidade, projeto, ano e município
Dados fictícios

Início: acesso unificado a mensagens, atividades, sistemas e questionários

Dados fictícios

Cruzamento de dados: Ceará Sem Fome x Projetos, por região, sexo e CadÚnico

Migração e Modernização por Módulos

Como Analista de Sistemas responsável pela evolução do produto, conduzi a migração do backend e frontend por módulos: cada tela do app foi reescrita e validada sem interromper o uso pelos servidores da Secretaria, que já dependiam do sistema no dia a dia.

API (.NET / C# / PHP)

Regras de negócio dos indicadores, chamados e questionários.

Filtros e relatórios

Consultas cruzadas por entidade, projeto, ano e município.

Mobile (React Native)

Experiência unificada dos servidores em campo e escritório.

Módulo migrado em produção

O módulo "Sistemas" foi reconstruído com filtros dinâmicos por entidade, projeto, ano e município, permitindo que servidores cruzem dados de diferentes iniciativas agrárias sem depender de planilhas externas.

Módulo Sistemas: filtro dinâmico por entidade, projeto, ano e município

Dados fictícios

Cadastro de beneficiário: formulário em etapas, com validação e rascunho automático

Arquitetura e Infraestrutura

O SDA Ceará não é um app de nicho: é usado por servidores de uma Secretaria de Estado, com picos de acesso concentrados em períodos de prestação de contas e acompanhamento de projetos em todos os municípios cearenses. Isso torna a infraestrutura tão crítica quanto o produto em si — a arquitetura foi desenhada para escalar horizontalmente, tolerar falhas de instância e permitir deploys frequentes sem indisponibilidade perceptível.

Containers imutáveis

Cada módulo (.NET, C# e PHP legado) empacotado em imagens Docker versionadas, com builds reprodutíveis independentes da máquina do desenvolvedor.

Orquestração e auto-scaling

Kubernetes com múltiplas réplicas por serviço e Horizontal Pod Autoscaler ajustando capacidade conforme CPU/memória nos picos de acesso estadual.

Resiliência de dados

PostgreSQL primário com réplica de leitura, isolando relatórios pesados da carga transacional e servindo de base para backups.

Rollout gradual

Pipeline de CI/CD publica novas versões dos módulos por rolling update, permitindo evoluir o sistema em produção sem parar o atendimento aos servidores.

Observabilidade fim a fim

Prometheus coleta métricas de cada pod, Grafana expõe dashboards operacionais e o Alertmanager dispara alertas antes que incidentes cheguem ao usuário final.

Isolamento entre módulos

Cada domínio (IDA, Atividades/MAPP, Questionário) roda como serviço independente, permitindo escalar, atualizar ou reiniciar um módulo sem afetar os demais.

CI/CD — build de imagem DockerPush no registry e rollout gradual no clusterReact Native + WebServidores em todo o CearáLoad BalancerTLSKUBERNETES CLUSTERIngress ControllerRoteia por módulo/domínioIDA — .NET3 réplicas · HPA 2–6Atividades / MAPP — C#2 réplicas · HPA 2–4Questionário — PHP2 réplicas (legado)HPA reequilibra réplicas por CPU/memória em picos de acesso estadualPostgreSQL — PrimárioLeitura e escritaPostgreSQL — RéplicaRéplica de leitura e backupsPrometheusColeta métricas dos podsGrafanaDashboards operacionaisAlertmanagerAlertas de incidentes

O resultado é uma infraestrutura pensada para escala estadual: serviços com múltiplas réplicas atrás de um Ingress Controller, banco de dados com réplica de leitura, e uma stack de observabilidade que dá visibilidade de produção antes que um problema afete os servidores da Secretaria em qualquer município do Ceará.

Integração de Múltiplos Módulos

MAPP: sistema de acompanhamento com dashboard próprio

Dados fictícios

Dashboard MAPP: projetos por região e status, filtrados por ano

Dados fictícios

Mensageria interna: histórico de conversas entre servidores e beneficiários

Além do IDA, o app integra o MAPP (Sistema de Acompanhamento) com seu próprio dashboard, o sistema de Questionários e a mensageria interna. Cada módulo mantém sua lógica de negócio própria, mas compartilha o mesmo shell de navegação e autenticação, reduzindo a curva de aprendizado para os servidores.

Princípios de integração

  • Autenticação e navegação únicas para todos os módulos
  • Ingress único roteando cada domínio para seu serviço, sem acoplar módulos entre si
  • Cada módulo migrado isoladamente, com rollback simples
  • Filtros e relatórios reutilizáveis entre módulos correlatos
  • Sem interrupção do uso por servidores durante a modernização

Segurança, Observabilidade e Decisões Técnicas

Um sistema estadual, acessado por servidores em todo o Ceará, exige que segurança e observabilidade sejam parte da arquitetura — não um apêndice. São essas camadas que mantêm o sistema seguro, observável e sustentável ao longo do tempo.

Segurança

  • Autenticação por token e acesso por perfil/setor da secretaria (RBAC)
  • TLS ponta a ponta no ingress; segredos por ambiente, fora do código
  • Dados administrativos sensíveis restritos por papel
  • Isolamento de rede entre serviços dentro do cluster

Observabilidade

  • Prometheus coletando métricas de todos os pods
  • Grafana com dashboards operacionais em tempo real
  • Alertmanager disparando alertas de incidente
  • Healthchecks + HPA reagindo a CPU/memória em picos estaduais

Decisões & trade-offs

  • Refatoração incremental: serviços .NET novos convivendo com módulo PHP legado, em vez de reescrita big-bang
  • Réplica de leitura do PostgreSQL para backups e relatórios sem pesar no primário
  • Kubernetes + HPA pela imprevisibilidade do acesso estadual: elástico em vez de instância fixa superdimensionada

Impacto do Projeto

O SDA Ceará hoje sustenta mais de 1.000 usuários ativos e mais de 200 logins simultâneos de servidores em todo o Estado, com backend e frontend totalmente migrados por módulos ao longo de 1,8 anos, sem interromper o trabalho diário da Secretaria do Desenvolvimento Agrário — e com uma infraestrutura em Kubernetes preparada para escalar conforme a demanda estadual cresce.

O projeto reforça que modernizar sistemas de governo em produção exige tanto rigor técnico quanto disciplina de processo: cada módulo precisa evoluir sem quebrar a confiança de quem já depende dele.

Trade-offs e o que eu faria diferente

O que optei por não fazer

  • Big-bang rewrite: descartei reescrever o sistema legado de uma vez. Com mais de 1.000 usuários já dependendo dele todo dia, migrar módulo por módulo levou mais tempo (1,8 anos), mas nunca interrompeu a operação da Secretaria.
  • Trocar o banco de dados durante a transição: mantive o PostgreSQL como fonte de verdade em vez de migrar de banco no meio do processo, pra não somar risco de dados a um projeto que já era arriscado por natureza.

O que eu faria diferente hoje

Introduziria feature flags desde o primeiro módulo migrado, não a partir do meio do projeto. Separar deploy de release teria dado mais margem pra testar cada módulo novo com um grupo pequeno de servidores antes de liberar pros 200+ logins simultâneos do Estado inteiro.

Principais Desafios Enfrentados

O SDA Ceará já era usado por servidores em produção quando entrei no projeto. Isso mudou completamente a natureza do trabalho: não era construir do zero, era evoluir um sistema em uso sem interromper a operação do Estado.

1Desafio

Migrar backend e frontend por módulos, sem downtime, com 1.000+ usuários ativos

2Desafio

Sustentar 200+ logins simultâneos com estabilidade em infraestrutura orquestrada

3Desafio

Unificar sistemas historicamente isolados (IDA, Questionário, MAPP, Ceará Sem Fome) em um único app

Indicadores Técnicos Estruturais

  • 1.000+ usuários ativos em produção
  • 200+ logins simultâneos suportados
  • Backend e frontend migrados por módulos, sem parar a operação
  • Observabilidade com Grafana e Prometheus
  • Orquestração de containers com Kubernetes

Stack Utilizada

React NativePostgreSQL.NETC#PHPDockerKubernetesGrafanaPrometheus

Gostou? Fale comigo!

Me envie uma mensagemVer outros projetos
© 2026 Francisco Pontes
Privacidade·Monte seu orçamento aqui·Conheça meu blog·Currículo