Meridian.

O problema

Reserva parece problema de interface e é problema de correção: disponibilidade, tarifas e confirmação de pagamento precisam permanecer consistentes sob concorrência. A pergunta interessante era como tornar overbooking e pagamento fantasma estruturalmente impossíveis, em vez de tratá-los no suporte.

O que tornou tecnicamente interessante

A disponibilidade precisa ser verificada no momento da reserva, sob concorrência — duas pessoas reservando o último quarto ao mesmo tempo precisam receber respostas verdadeiras.

O estado do pagamento e o estado da reserva vivem em dois sistemas (a aplicação e o provedor de pagamento). Manter os dois sincronizados é onde a maioria dos sistemas de booking escorrega.

Cada propriedade precisa da própria identidade, mas um fork por propriedade transformaria cada correção em operação de frota.

Decisões

Disponibilidade como invariante central

Reservas, retenções e restrições de tarifa passam por um único serviço de disponibilidade com checagens transacionais. Overbooking deixou de ser chamado de suporte e virou impossibilidade estrutural.

Pagamento confirmado por webhook, não por redirect

A reserva só confirma quando o webhook do Stripe chega — usuário fechando a aba depois de pagar não cria mais reserva fantasma.

Identidade por propriedade sem código por propriedade

Paleta, tipografia e imagens são configuração, não fork — uma propriedade nova é um passo de onboarding, não um deploy.

Resultado

• O serviço de disponibilidade torna reservas conflitantes impossíveis no nível do banco de dados, não por convenção.
• O estado do pagamento só avança por eventos de webhook — o sistema nunca exibe uma reserva confirmada que não foi paga.
• Propriedades são dados — o protótipo demonstrou que uma propriedade nova não exige mudança de código.