Desenvolvimento de Soluções Web Personalizadas

1. Contexto e Levantamento de Requisitos

Antes de escrever uma linha de código, dedicamos duas sessões de levantamento de requisitos com a organização do evento. Mapeamos todos os fluxos existentes — mesmo os manuais — para entender o que precisava ser automatizado e o que devia permanecer flexível.

Os principais fluxos identificados foram:

• Fluxo do participante: descobrir o evento → ler regulamento → realizar inscrição → pagar → receber confirmação → consultar resultado
• Fluxo do organizador: configurar evento (categorias, datas, limites de vagas, valores) → acompanhar inscrições em tempo real → controlar pagamentos → comunicar participantes → gerar relatórios → publicar resultados
• Fluxo financeiro: inscrição com valor variável por categoria → split de pagamento quando aplicável → conciliação automática

Uma decisão importante tomada nessa fase: não construir um sistema genérico de eventos. O escopo e os requisitos eram suficientemente específicos para justificar uma aplicação dedicada, com terminologia e fluxos do domínio do cliente embutidos no produto — o que resulta em UX muito superior a uma solução genérica adaptada.

2. Decisões de Arquitetura e Stack

2.1 Stack escolhida

Optamos por Laravel 11 + MySQL 8 + Tailwind CSS + Alpine.js no frontend público, com Livewire para o painel administrativo. O racional:

• Laravel oferece ORM robusto, filas de jobs nativas (para e-mails assíncronos), autenticação pronta e ecossistema maduro para pagamentos
• Livewire permite construir interfaces reativas no painel admin sem a complexidade de manter um frontend SPA separado — dado que o painel é usado apenas pelo organizador, a performance de SPA não era requisito
• MySQL 8 foi escolhido pela familiaridade do ambiente de hospedagem do cliente e suporte nativo a JSON columns, usadas para armazenar configurações flexíveis de categoria

2.2 Modelagem do banco de dados

O schema central girou em torno de 5 entidades principais: eventos, categorias, participantes, inscricoes e pagamentos. A relação entre categorias e inscrições usou uma coluna JSON para armazenar as configurações específicas de cada categoria (campos adicionais variáveis por tipo de competição), evitando o anti-pattern de criar dezenas de colunas nullable ou tabelas EAV.

Todos os soft deletes foram implementados para preservar histórico — nunca apagar um registro de inscrição ou pagamento, mesmo que cancelado.

2.3 Integração de pagamentos

Integramos com um gateway de pagamentos via SDK oficial, suportando cartão de crédito, Pix e boleto. Todos os webhooks de confirmação de pagamento foram implementados com verificação de assinatura HMAC para garantir autenticidade — somente eventos genuinamente originados pelo gateway alteram o status de uma inscrição. Armazenamos apenas o payment_id do gateway, nunca dados sensíveis de cartão — conformidade total com PCI-DSS pelo modelo de tokenização.

3. Implementação: Destaques Técnicos

3.1 Controle de concorrência nas vagas

Quando múltiplos participantes tentam se inscrever simultaneamente na última vaga disponível, a lógica trivial de "verificar se há vaga → criar inscrição" falha sob condição de corrida. Implementamos o controle com pessimistic locking no MySQL: a query de decremento de vagas usa SELECT ... FOR UPDATE dentro de uma transaction, garantindo que apenas uma requisição por vez altere o contador — as demais aguardam ou recebem erro controlado de "sem vagas".

3.2 E-mails transacionais assíncronos

Todos os e-mails (confirmação de inscrição, confirmação de pagamento, lembretes, resultados) são disparados via fila de jobs do Laravel com driver Redis. Isso garante que a resposta HTTP ao participante seja imediata — sem esperar pelo envio do e-mail — e que falhas no servidor de e-mail sejam retentadas automaticamente com backoff exponencial, sem perder mensagens.

3.3 Painel administrativo em tempo real

O painel usa broadcasting via Pusher para atualizar os contadores de inscrições e pagamentos em tempo real sem necessidade de refresh. O organizador vê o dashboard "vivo" durante o período de inscrições abertas. Livewire components foram usados para formulários de configuração de evento com validação em tempo real no servidor, sem JavaScript manual.

3.4 Responsividade e acessibilidade

O frontend público foi desenvolvido com mobile-first desde o início — a maioria dos participantes acessa pelo celular. Testamos em dispositivos reais com conexão 3G para garantir que o fluxo de inscrição completo fosse concluível mesmo em condições de rede ruim. Todas as imagens são servidas em WebP com fallback PNG, e formulários foram validados com leitores de tela.

4. Processo de Desenvolvimento e Entrega

O projeto foi conduzido em 3 sprints de 2 semanas cada. Ao final de cada sprint, apresentamos uma versão funcional para validação do cliente — não apenas wireframes. Isso permitiu ajustes de fluxo nas semanas 2 e 4 sem custo elevado de mudança, e o cliente sempre sabia exatamente o que estava sendo construído.

Na sprint 3, realizamos um soft launch com um evento menor (50 vagas) para validar todos os fluxos em produção real antes do evento principal. Três pequenos ajustes de UX foram identificados nesse soft launch e corrigidos antes do lançamento completo.

5. Resultados Mensurados (primeiro evento pós-lançamento)

Adicionalmente, o NPS coletado dos participantes após o evento foi de 87 — os comentários mais frequentes mencionavam a facilidade do processo de inscrição e a rapidez da confirmação por e-mail.

6. Lições Aprendidas

• Levantar requisitos com foco em fluxos, não em telas: perguntar "o que você precisa que o sistema faça?" leva a listas de funcionalidades; perguntar "me mostra como você faz isso hoje, passo a passo" revela o problema real e os edge cases que um briefing nunca capturaria.
• Soft launch antes do lançamento real: nenhum teste unitário substitui usuários reais em produção. Reservar um evento menor para validação evita que problemas de UX apareçam no momento de maior pressão.
• Concorrência precisa ser pensada desde o design: problemas de race condition em vagas só aparecem em produção, com múltiplos usuários simultâneos. A decisão de usar pessimistic lock foi tomada no design, não como correção emergencial.
• Domínio específico > solução genérica: uma plataforma de eventos genérica teria sido mais rápida de entregar, mas o produto final seria mais difícil de usar para o cliente. Termos como "categoria", "número de catálogo" e "ficha técnica do animal" estão no código e na interface, não escondidos atrás de "campo customizável 1".