Dois usuários visualizam o mesmo horário livre, confirmam quase juntos e recebem uma mensagem de sucesso. A interface funcionou para ambos, mas a operação ganhou um conflito. O problema é de concorrência: o intervalo estava disponível quando foi consultado, porém deixou de estar antes da segunda gravação.
Um sistema de agendamento confiável valida a disponibilidade no momento da confirmação e protege a regra no servidor e no banco. Calendários bonitos são importantes, mas não garantem que uma sala, um profissional ou um equipamento estará disponível.
1. Defina o recurso que está sendo reservado
Uma reserva pode exigir vários recursos simultaneamente: profissional, sala e equipamento. Também pode admitir capacidade maior que um, como uma turma. Modele a unidade de capacidade e as dependências antes de escolher o componente visual de calendário.
Registre duração, preparação, deslocamento e limpeza quando consumirem disponibilidade. Uma reunião de uma hora com quinze minutos de preparação pode bloquear mais tempo que o intervalo apresentado ao cliente. Horários de trabalho, feriados e exceções pertencem à regra, não apenas à decoração da agenda.
2. Estabeleça a semântica do intervalo
Defina se o término de uma reserva pode coincidir com o início da seguinte. Uma convenção comum usa início incluído e fim excluído, permitindo agendamentos adjacentes sem tratá-los como sobreposição. Essa convenção deve ser consistente na consulta, no armazenamento e na interface.
Trabalhe com instantes e fusos de forma explícita. Uma operação com clientes em diferentes regiões precisa exibir qual horário está sendo confirmado. Para recorrências, diferencie a intenção local, como “toda terça às nove”, de uma repetição por quantidade fixa de segundos.
| Regra | Decisão necessária | Evidência na interface |
|---|---|---|
| Capacidade | Exclusiva ou compartilhada | Vagas restantes |
| Duração | Fixa ou variável | Início e término |
| Bloqueio adicional | Preparação e intervalo | Disponibilidade consistente |
| Fuso | Local do recurso ou do cliente | Identificação do horário |
| Recorrência | Série e exceções | Escopo da alteração |
3. Separe consulta de confirmação
A lista de horários disponíveis é uma fotografia temporária. Ao confirmar, revalide permissões, recursos, capacidade e conflito dentro de uma operação protegida. Se o horário acabou de ser ocupado, responda com alternativas atualizadas, sem apresentar sucesso provisório como definitivo.
No PostgreSQL, mecanismos de restrição, inclusive exclusão, podem apoiar invariantes de intervalos. A escolha depende do modelo de capacidade e dos estados considerados ocupados. Uma restrição correta para reserva exclusiva pode não resolver um recurso com dez vagas.
4. Trate disputas simultâneas
Uma sequência “consultar, depois inserir” executada sem proteção pode falhar sob concorrência. A estratégia pode envolver bloqueio do recurso, atualização condicional de capacidade ou restrição de integridade, com transação e tratamento de conflito. O nível de isolamento deve corresponder à regra.
A documentação de isolamento de transações explica garantias e situações de repetição de transações. Na aplicação, planeje uma nova tentativa limitada quando apropriado e uma resposta compreensível quando o horário não estiver mais disponível.
5. Use reservas temporárias com expiração
Se o cliente precisa preencher dados ou realizar pagamento, pode ser útil segurar o horário por um prazo. Essa retenção precisa de expiração confiável e de uma política para o pagamento que chega depois. Um cronômetro apenas no navegador não libera o recurso no servidor.
Defina estados como temporária, confirmada, cancelada, expirada e concluída. Especifique quais estados consomem capacidade. Um processo periódico pode limpar retenções antigas, mas a confirmação também precisa verificar a expiração, pois tarefas agendadas podem atrasar.
6. Modele reagendamento e cancelamento
Reagendar é mais do que editar duas datas. A operação deve garantir a nova disponibilidade e preservar a reserva antiga se não conseguir concluir a troca. Em alguns contextos, a mudança exige aprovação ou comunicação a participantes.
No cancelamento, registre responsável, motivo e momento. Regras comerciais de prazo e cobrança devem ser definidas pela empresa e refletidas no contrato aplicável. O software não deve improvisar condições. Para séries recorrentes, ofereça opções claras: apenas esta ocorrência, as seguintes ou toda a série.
7. Exemplo hipotético de disputa
Uma consultoria possui uma sala e dois profissionais. Duas empresas solicitam a mesma sala às 14h. A primeira transação confirma a reserva. A segunda encontra conflito e recebe 15h e 16h como alternativas. Nenhuma confirmação duplicada é enviada.
Se um profissional puder atender remotamente, essa possibilidade não deve ser inferida pelo sistema: precisa existir como modalidade e regra. A disponibilidade de um recurso não implica a disponibilidade dos demais. Esse é um dos motivos para testar combinações completas, não apenas a agenda individual.
8. Notificações e integrações
Envie confirmação somente depois de a reserva estar efetivamente gravada. Identifique a versão ou alteração a que a mensagem se refere. Um lembrete antigo não pode orientar o cliente sobre um horário já reagendado.
Ao integrar calendários externos, defina a fonte de verdade e a latência aceitável. Se a sincronização for assíncrona, explique o período de incerteza e trate conflitos. Credenciais, escopos e cancelamentos também fazem parte do desenho. Evite permitir que uma integração secundária sobrescreva indiscriminadamente o estado principal.
Checklist de testes
- Confirmar o mesmo horário por duas sessões simultâneas.
- Testar intervalos adjacentes e sobrepostos.
- Verificar múltiplos recursos e capacidade compartilhada.
- Expirar uma retenção durante a confirmação.
- Reagendar para um horário ocupado e preservar o original.
- Cancelar uma ocorrência de uma série.
- Simular atraso de pagamento e de sincronização.
- Conferir o fuso mostrado em todas as mensagens.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre responsáveis, verificações e observações da implantação.
Perguntas frequentes
Bloquear o botão após o clique resolve?
Ajuda contra repetição na mesma tela, mas não impede outra sessão ou integração. A garantia deve existir no backend.
Posso confirmar antes de receber o pagamento?
É uma decisão comercial. O sistema precisa distinguir reserva, confirmação e pagamento para implementar a política escolhida.
Preciso construir tudo do zero?
Nem sempre. Compare ferramentas existentes com recursos, integrações e regras realmente necessárias antes de decidir.
Para avaliar uma agenda integrada à operação, converse com a A2CR.
Autoria: Agência A2CR. Revisão editorial: 9 de novembro de 2026. Exemplo hipotético; roteiro arquitetural elaborado pela A2CR com apoio das referências técnicas vinculadas.
