Evite marcações duplicadas: porque falham os sistemas, e o modelo que não pode falhar
A dupla marcação quase nunca acontece porque um calendário «cometeu um erro». Acontece porque o software verificou se uma vaga estava livre, e reservou-a, como dois passos separados com um intervalo entre eles — e um segundo cliente escapuliu-se por esse intervalo. Feche esse intervalo e o resto do calendário pode ser tão simples ou elaborado quanto quiser. Deixe-o aberto, e nenhuma quantidade de polimento no widget de marcações impede que duas pessoas acabem ocasionalmente na mesma cadeira.
Onde a diferença realmente aparece
A sequência habitual por trás de quase qualquer marcação: verificar «esta vaga ainda está livre?», receber «sim», depois escrever a marcação. Uma leitura, depois uma escrita — e entre as duas, por muito breve que seja, uma janela. Um segundo pedido que verifica a mesma vaga durante essa janela também vê «sim, ainda livre». Ambos passam a acreditar que estão a marcar uma vaga aberta, porque no momento em que cada um olhou, estava.
Não consegue perceber, clicando numa demonstração numa tarde de terça-feira tranquila, se a verificação e a escrita por baixo estão em segurança unidas ou perigosamente separadas — o calendário parece idêntico de qualquer das formas.
Porque "basta um calendário mais bonito" não resolve
Muito software de marcações é, por baixo do widget, um construtor de formulários genérico que nunca foi concebido para duas pessoas a reclamarem a mesma coisa finita ao mesmo tempo. A escolha de data pode ser fluida, a disponibilidade parecer em tempo real, o ecrã de confirmação limpo — e o back end continua a verificar com uma leitura e a escrever com uma escrita separada e posterior. Tráfego real e simultâneo encontra a costura.
O modelo que realmente fecha a lacuna
Deixe de tratar «verificar» e «reservar» como duas operações: execute de novo a verificação de disponibilidade e escreva a marcação dentro de uma única transação de base de dados que bloqueia as linhas dessa vaga. O pedido que chegar primeiro termina a sua verificação-e-escrita sem interrupção; o segundo espera a sua vez, e depois volta a verificar face à nova realidade. Não sobra nenhuma janela em que informação desatualizada de «ainda disponível» possa ser usada — é a base de dados que impõe a ordem, e não o código da aplicação a torcer para que nada entre em corrida.
O que acontece realmente quando duas pessoas clicam em «reservar» ao mesmo tempo
1
Os dois pedidos chegam quase ao mesmo tempo
2
Um pedido obtém o bloqueio primeiro
3
O primeiro pedido volta a verificar e escreve, tudo de uma vez
4
O segundo pedido volta a verificar face à nova realidade
5
O segundo cliente é avisado de imediato
Como a Olmira trata disto
O motor de marcações da Olmira executa a reverificação de disponibilidade e a gravação da marcação como um só passo, dentro de uma única transação de base de dados bloqueada — por isso, quando dois clientes vão atrás do mesmo horário ao mesmo tempo, uma marcação é confirmada e à outra é dito, antes de qualquer dinheiro se mover, que o horário acabou de sair. O mesmo bloqueio cobre o recurso subjacente, e não apenas o serviço que está a ser vendido, pelo que dois serviços diferentes que partilham uma sala ou um membro da equipa também não o podem duplicar entre si sem que ninguém dê por isso. Uma salvaguarda separada e mais pequena apanha o acidente mais comum — o mesmo cliente a fazer duplo clique em «marcar» — e pede-lhe que confirme, em vez de criar silenciosamente duas marcações. Veja como tudo encaixa na página de marcações.
Guias relacionados
Faltas: o que move realmente o número
Não — muito tráfego apenas faz com que apareça mais cedo. A falha de base existe a partir do momento em que mais do que um pedido pode estar em curso para o mesmo horário, o que é verdade mesmo numa página com pouco movimento; um negócio com pouco tráfego pode simplesmente passar meses entre os raros momentos em que duas pessoas clicam ao mesmo tempo. É uma propriedade do desenho, não uma função do movimento que tem.
Não. O calendário é o que o cliente vê; a parte que impede a marcação em duplicado acontece inteiramente no servidor, de forma invisível, no instante exacto em que uma reserva é gravada. Uma interface de calendário bem-acabada não lhe diz nada sobre o que acontece por baixo quando duas pessoas clicam no mesmo intervalo no mesmo segundo.
Devem saber de imediato — antes de ser cobrado qualquer pagamento — que o horário acabou de ser ocupado, e ver a próxima opção realmente disponível. O modo de falha que preocupa é o oposto: um sistema que deixa passar as duas reservas e só revela o conflito mais tarde, normalmente quando alguém aparece.
O mesmo mecanismo aplica-se sempre que se reserva algo partilhado e finito: uma mesa, uma sala, um equipamento, uma janela de entrega. A solução tem sempre a mesma forma: bloquear e voltar a verificar o recurso realmente limitado no momento do compromisso, e não um momento antes.
Sim, em sectores específicos — as companhias aéreas vendem historicamente mais lugares do que têm, contra uma taxa prevista de não comparência, como decisão de negócio deliberada e modelada, com uma política de compensação associada. Isso é coisa diferente do tipo acidental de que trata este guia, em que ninguém o pretendeu e ninguém fica satisfeito ao descobri-lo.