Caso de sistema de agendamento da clínica via LINE: controle de concorrência, sincronização em tempo real e teste 130+

Contexto do problema

O maior risco em um sistema de agendamento não é a aparência da interface, mas a competição nos níveis de dados: dois pacientes enviam solicitações para o mesmo horário, a clínica suspende temporariamente, mas o paciente ainda vê o horário anterior, ou as regras de agendamento são atualizadas, mas o LINE ainda permite. Esses cenários não ocorrem durante a demonstração, mas certamente ocorrerão em condições de tráfego real. O foco deste caso é separar o "aparência de que é possível agendar" do "fato de ter agendado" no banco de dados, e garantir que qualquer alteração no back-end seja refletida em tempo real no lado do paciente.

Forma de implementação

• —Agendamento simultâneo com bloqueio de banco de dados e processamento de transações: ao agendar, a hora é consultada e bloqueada novamente dentro da transação. Quando dois pacientes enviam solicitações simultaneamente, apenas quem obtiver o bloqueio primeiro terá sucesso, e o outro receberá uma mensagem clara de falha, evitando a falsa impressão de que ambos tiveram sucesso.
• —Estado de não confiança na interface: Os horários disponíveis na tela são apenas uma referência. A confirmação da reserva depende exclusivamente da verificação posterior no servidor: se o horário ainda está disponível, se o paciente atende aos requisitos e se não há conflito com reservas existentes.
• —Utilização do Supabase Realtime para sincronização: Quando o atendimento é interrompido, os horários são ajustados ou as regras são modificadas, as alterações são enviadas imediatamente para a interface do paciente, reduzindo a discrepância de informações. No entanto, a verificação posterior no servidor ainda é a principal, e o Supabase Realtime é responsável pela experiência do usuário, não pela correção.
• —Criação de testes de ponta a ponta para cenários de exceção: Cenários como agendamento simultâneo, cancelamento imediato após o agendamento, interrupção temporária do atendimento, verificação após a alteração das regras e reenvio após a interrupção da conexão devem ser convertidos em testes repetíveis, permitindo a execução completa após cada modificação.

Escopo real de responsabilidade do Falcon

• Fluxo de agendamento de pacientes via LINE LIFF
• Painel de gerenciamento de horários e agendamentos da clínica
• Sincronização em tempo real com Supabase Realtime
• Controle de concorrência e testes de ponta a ponta no banco de dados

Fluxo de agendamento e controle de concorrência via LINE

1. 01O paciente abre a interface de agendamento do LINE LIFF, carregando os horários disponíveis. Esta lista é apenas uma referência visual, não o critério final.
2. 02Ao enviar a reserva, o servidor verifica novamente o status da disponibilidade do horário, a conformidade com as regras e a ausência de conflitos, e apenas se tudo estiver correto, a reserva é registrada.
3. 03Quando duas pessoas tentam agendar o mesmo horário simultaneamente, o banco de dados determina quem tem sucesso. O servidor que falhou recebe uma mensagem clara e recarrega os horários disponíveis mais recentes.
4. 04O Supabase Realtime sincroniza as alterações de horário e as alterações no painel com o cliente e o painel de gerenciamento da clínica, garantindo que ambos vejam o mesmo status.

Limitações, falhas e alternativas

• —Quando várias pessoas tentam agendar o mesmo horário simultaneamente, o resultado da transação no servidor determina quem tem sucesso. O servidor que falhou deve escolher novamente, sem assumir que "quem chega primeiro, serve primeiro".
• —Não se pode assumir que a reserva foi bem-sucedida em caso de interrupção imediata da conexão. A tela deve ser atualizada com o status real no servidor antes de exibir os resultados.
• —O tempo de aplicação das alterações nas regras é determinado pelo servidor. Se a tela do cliente ainda não for atualizada, a reserva enviada ainda será verificada pelo servidor.
• —Os casos anônimos não divulgam informações sobre pacientes, clínicas, número de agendamentos e dados médicos, nem afirmam sobre resultados médicos ou operacionais.

Como verificar as evidências

• ✓Os 130+ testes de ponta a ponta abrangem: agendamento e cancelamento normais, tentativas simultâneas de reservar o mesmo horário, alterações de horários pelo painel e suspensões temporárias do atendimento, verificação de reservas após mudanças nas regras, interrupções de conexão e reenvios.
• ✓Os números de teste representam o número de casos documentados em trabalhos públicos existentes, não indicando a ausência de defeitos.
• ✓O bloqueio de banco de dados, transações e Supabase Realtime descrevem o design do sistema, não representando nenhum compromisso operacional.
• ✓Nomes de clientes, dados de pacientes, número de agendamentos e indicadores operacionais não são divulgados.

Medições e capacidades disponíveis