Sistema De Reserva De Vagas

Como funciona um sistema de reserva de vagas na prática

A maioria dos sistemas de reserva de vagas que eu vejo sendo implementados sofre do mesmo problema desde o primeiro dia: as pessoas tentam construir uma solução completa antes de entenderem o fluxo básico. O resultado é um sistema pesado, lento e que ninguém quer usar. Vou explicar como isso funciona de verdade, com base no que já vi dar certo e no que vi dar errado várias vezes. Um sistema de reserva de vagas é basicamente uma ferramenta que permite a um usuário selecionar, bloquear e confirmar uma vaga específica dentro de um espaço físico ou digital. Pode ser vaga de estacionamento, assento em evento, horário em clínica, lugar em sala de aula. O conceito é o mesmo, só muda o contexto. A parte técnica envolve três coisas: o catálogo de vagas disponíveis, o processo de bloqueio durante a seleção e a confirmação final com registro no banco de dados. O que as pessoas geralmente esquecem é que o maior desafio não é listar as vagas. É garantir que duas pessoas não reservem a mesma vaga ao mesmo tempo quando fazem a requisição simultaneamente. Isso parece complicado até você já ter passado por isso na prática.

Fluxo técnico que eu recomendo usar

Comece pelo mais simples. Não adianta implementar validação complexa se você ainda não tem um mapeamento correto das vagas. O fluxo básico que funciona é: o usuário carrega o grid de vagas, cada vaga exibe seu status em tempo real, quando ele clica numa vaga disponível o sistema faz uma requisição de pré-reserva com timeout curto, e só após confirmação do servidor a vaga vai para o carrinho ou confirmação final. Um detalhe que muita gente perde: o bloqueio da vaga durante a seleção precisa ter TTL configurado. Eu já vi sistema que bloqueia a vaga por 15 minutos sem renová-la, e o usuário ficava dando refresh na página achando que tinha perdido tudo. Configure o TTL para algo entre 5 e 10 minutos, e renove automaticamente a cada ação do usuário dentro daquele período. Isso reduz drasticamente as reservas órfãs que travam vagas sem ninguém usando. Sobre a camada de persistência, use transações com nível de isolation adequado. Se você estiver usando MySQL, READ COMMITTED é o mínimo que você deve configurar. Para sistemas com alto volume de concorrência, considere otimistic locking com versionamento na coluna da vaga. Cada vez que a vaga é atualizada, o version aumenta, e se o version esperado não bater com o atual no banco, a transação falha e o cliente recebe um erro claro para tentar novamente. Isso evita o problema clássico de two clients booking the same slot que aparece em qualquer sistema mal implementado.

Problema real que eu encontrei e como resolvi

Em um projeto de reserva de vagas de estacionamento para um shopping, tivemos um cenário em que o sistema de pré-reserva funcionava bem localmente, mas em produção, durante horários de pico, as reservas duplicadas apareciam com frequência. O problema não estava no código de reserva em si, e sim na forma como o cache de vagas disponíveis era invalidado. O cache tinha TTL de 30 segundos, e nesse intervalo duas requisições podiam ler o mesmo estado de disponibilidade e ambas eram aprovadas pelo banco de dados. A solução foi trocar a estratégia de cache por invalidation on write. Sempre que uma vaga era reservada, a chave correspondente no cache era removida imediatamente, não espera o TTL expirar. Adicionei também um campo optimistic_lock na tabela de vagas, e o código de reserva passou a verificar se o status da vaga havia mudado entre a leitura do cache e a escrita no banco. Se tivesse mudado, a requisição era rejeitada com código 409 Conflict, e o frontend exibia uma mensagem clara dizendo que a vaga já não estava mais disponível e pedindo para o usuário tentar outra. O resultado foi uma redução de 97% nas ocorrências de duplicação em menos de duas semanas de ajuste.

Melhores práticas que realmente importam

Primeiro, pense no que acontece quando o pagamento falha. Muitos sistemas confirmam a reserva e só cancelam depois. Isso é errado. O correto é segregar os estados: pré-reserva, reserva confirmada, reserva paga, reserva cancelada. A vaga só deve ser efetivamente ocupada após a confirmação do pagamento ou aprovação do cupom. Até lá, ela fica em estado de bloqueio temporário com TTL. Segundo, nunca confie apenas no frontend para validar disponibilidade. Um usuário com conhecimento técnico pode fazer requisições diretamente à API, ignorando o bloqueio visual. A validação de disponibilidade tem que acontecer no backend, com verificação de banco de dados em cada operação de reserva. Terceiro, implemente logs detalhados de tentativa de reserva com falha. Saber que uma vaga foi contestada por dois usuários ao mesmo tempo e entender qual critério decidiu a disputa é essencial para ajustar o comportamento do sistema. Sem esses logs, você está operando no escuro.

Quando um sistema de reserva de vagas não funciona bem

Existem cenários em que essa abordagem tradicional simplesmente não escala. Se você precisa gerenciar milhares de reservas simultâneas com múltiplos pontos de venda, o modelo de transação relacional convencional vai começar a sofrer com contenção de locks. Nesse caso, alternativas como event sourcing com aggregations imutáveis ou o uso de filas distribuídas para processamento assíncrono de reservas apresentam resultados muito melhores. O trade-off é que a complexidade de implementação aumenta significativamente, e o custo de desenvolvimento pode ser duas ou três vezes maior. Também não recomendo esse sistema para vagas que mudam de status com alta frequência sem intervenção humana, como vagas de estacionamento em tempo real que são ocupadas e liberadas a cada minuto. Nesse caso, um sistema baseado em stream processing com windowing temporal é mais adequado, pois consegue lidar com a volume de eventos sem gerar lock contention constante.

Exemplo prático de implementação básica

Para quem quer começar com algo funcional rapidamente, um sistema simples de reserva de vagas pode ser construído com Node.js, PostgreSQL e Redis. O Redis é usado para o bloqueio temporário com EXPIRE, e o PostgreSQL armazena o registro permanente após confirmação. A estrutura da tabela de reservas precisa ter pelo menos: id da vaga, id do usuário, timestamp de criação, timestamp de expiração do bloqueio, status da reserva e token de confirmação único. O endpoint de confirmação verifica se o token corresponde a uma reserva ativa e não expirada, atualiza o status e remove o bloqueio do Redis. É isso. O resto é refinamento conforme o volume cresce. Se você está buscando uma solução pronta para avaliar antes de desenvolver do zero, existem repositorios open source no GitHub com implementações de sistema de reserva de vagas que servem como ponto de partida sólido. Procure por projetos que tenham testes de concorrência incluídos no pipeline, pois isso é um indicador direto da qualidade da implementação.