Como o Airbnb Reconstruiu a Autenticação com Arquitetura Server-Driven

Autenticação é a porta de entrada para o seu produto. Em uma plataforma como o Airbnb, onde um login falho significa uma reserva perdida e receita perdida tanto para o hóspede quanto para o anfitrião, acertar nesse fluxo é crítico. O sistema antigo, que cresceu organicamente ao longo de uma década, tratava a autenticação como uma única pergunta: "Essa pessoa consegue provar quem é?" Mas, como eles descobriram, a pergunta real é mais sutil: "Dado o que sabemos sobre essa pessoa e seu contexto, qual é a maneira mais fácil de ela verificar sua identidade?"

Essa percepção levou a uma reformulação completa dos fluxos de autenticação, resultando no que eles chamam de Flexible Authentication. A ideia central é dividir o processo em duas etapas distintas: primeiro, identificar o usuário e, depois, desafiá-lo com o método de verificação mais adequado. Este artigo mergulha na arquitetura e nos princípios por trás dessa mudança de paradigma.

Os Princípios Fundamentais

Identificar Primeiro, Desafiar Depois

O sistema antigo forçava os usuários a uma sequência fixa: inserir e-mail, depois senha, e talvez um segundo fator. Se você não tivesse as credenciais certas, estava preso. O novo modelo inverte isso. O usuário primeiro fornece um identificador (e-mail, telefone ou login social). O servidor então usa um mecanismo de política configurável para selecionar o desafio com maior probabilidade de sucesso para aquele usuário e contexto específicos.

Por exemplo, um viajante no Brasil que se registrou com número de telefone é melhor atendido por um OTP do WhatsApp do que por SMS, dada a maior penetração do WhatsApp. Um anfitrião na Coreia do Sul pode preferir o login Naver, o principal provedor de identidade local, em vez do Google. O mecanismo de política pode aproveitar dados históricos e atributos de sessão para tomar essa decisão.

Telas Server-Driven

A decisão arquitetural mais significativa foi tornar o cliente um renderizador fino. O servidor define cada tela (entrada de identificador, desafio, seletor de conta, recuperação de erro) como um esquema. O cliente simplesmente exibe a tela e envia ações, sem lógica de sequenciamento ou fluxo. Essa separação permite experimentação rápida e ajuste por região sem esperar pelas revisões da loja de aplicativos.

// Exemplo de resposta do servidor para uma tela de desafio
{
  "screen": "challenge",
  "primaryChallenge": "whatsapp_otp",
  "alternatives": [
    {"type": "sms_otp", "label": "Envie-me um código por SMS"},
    {"type": "email_otp", "label": "Envie-me um código por e-mail"},
    {"type": "password", "label": "Usar minha senha"}
  ],
  "sessionId": "abc123"
}

Sem Becos Sem Saída: O Challenge Picker

Um princípio fundamental do produto era que cada tela deve oferecer uma saída. Se um usuário não conseguir concluir o desafio principal, ele deve sempre ver uma opção "Tente outra forma". Isso é implementado como um Challenge Picker, um componente server-driven que acompanha cada tela de desafio. Ele retorna uma lista classificada de métodos alternativos, ordenados pela taxa de sucesso prevista.

Resultados e Lições Aprendidas

A mudança do Airbnb para um modelo server-driven produziu resultados impressionantes:

• Redução de 60% no código do cliente e redução de 100KB no tamanho do bundle web.
• Mais de 20 experimentos em três meses, com o tempo de resposta de ideias caindo de semanas para dias.
• Aumento de 2,6% nas autenticações bem-sucedidas, impactando milhões de sessões.
• Diminuição de 27% em contas duplicadas, preservando histórico de viagens e reservas.
• Redução de 11% nos custos com OTP ao liderar com o desafio mais eficaz.

Possíveis Armadilhas e Considerações

Embora os benefícios sejam claros, essa arquitetura não está isenta de desafios:

• Latência do servidor: Cada transição de tela requer uma ida e volta ao servidor, o que pode impactar o desempenho percebido, especialmente em redes lentas.
• Complexidade no mecanismo de política: A lógica para selecionar o melhor desafio é intrincada e requer ajustes constantes para evitar viés ou má experiência do usuário.
• Suporte offline: Uma abordagem server-driven é inerentemente dependente da conectividade de rede, tornando a autenticação offline impossível.

Conclusão

O Flexible Authentication do Airbnb é um exemplo poderoso de como insights de produto podem impulsionar decisões arquiteturais. Ao mover o limite de decisão para fora do cliente e para o servidor, eles desbloquearam a capacidade de iterar rapidamente e personalizar a experiência de autenticação em escala. Os princípios de identificar-primeiro-desafiar-depois, telas server-driven e sem becos sem saída são diretamente aplicáveis a qualquer equipe que construa autenticação para uma base de usuários global.

Se você está procurando melhorar seus próprios fluxos de autenticação, considere adotar uma abordagem server-driven semelhante. Para um mergulho mais profundo em gerenciar custos e ROI de recursos impulsionados por IA, confira nosso guia sobre maximizando o ROI de IA e gerenciando custos. Além disso, explore como fortes loops de feedback em agentes de codificação de IA podem aprimorar seu fluxo de trabalho de desenvolvimento.

Próximos Passos para Aprender

• Estude o Padrão: Analise como outras empresas como Netflix e Spotify usam UIs server-driven para seus próprios recursos dinâmicos.
• Prototipe um Fluxo Simples: Construa um fluxo de login server-driven mínimo com um framework como React e um servidor mock.
• Aprofunde-se em Mecanismos de Política: Aprenda sobre sistemas baseados em regras e modelos de machine learning que podem alimentar sua própria lógica de seleção de desafios.