App de match (Tinder)

01 · CONTEXTO E REQUISITOS

O que um app de match precisa fazer

Um app de match mostra uma pilha de perfis, e a pessoa desliza para curtir ou passar. Quando duas pessoas se curtem, o app avisa as duas. O foco do exercício é a pilha de perfis e o swipe, não o chat nem as fotos.

Funcionalmente, a pessoa cria um perfil com preferências e distância máxima, vê uma pilha de perfis dentro desses limites e desliza em cada um. Do lado não funcional, quatro exigências mandam no desenho: consistência forte no swipe, escala para muitos usuários diários, pilha carregada com baixa latência e nenhum perfil repetido.

02 · API E PRIMEIRA VERSÃO

Três endpoints e dois serviços

A API tem uma rota para o perfil (POST /profile), outra para a pilha (GET /feed, que recebe a localização atual do cliente) e outra para o swipe (POST /swipe/{userId}).

A primeira versão separa o serviço de perfis do serviço de swipes, cada um com seu banco. A razão é que o perfil é criado e visto muito menos vezes do que os swipes são gravados, então o serviço de swipes precisa escalar sozinho. Para o volume de escrita, a fonte escolhe Cassandra, particionado pelo usuário que desliza, aceitando consistência eventual como contrapartida.

1. O app envia o pedido ao API Gateway.

2. Pedidos de perfil e de pilha vão ao serviço de perfis, que consulta o banco de perfis.

3. Cada swipe vai ao serviço de swipes, que grava no banco de swipes e procura o swipe inverso.

4. Se o inverso existir, quem acabou de deslizar vê o match na hora e quem curtiu antes recebe um push.

03 · CONSISTÊNCIA DO SWIPE

Quando duas pessoas se curtem ao mesmo tempo

O risco é uma corrida. Se os dois swipes chegam quase juntos, cada servidor procura o swipe inverso e não acha nada; depois os dois swipes são gravados. Os dois ficam salvos, mas a chance de avisar o match se perdeu.

A fonte lembra que dá para relaxar a consistência e rodar uma reconciliação periódica que notifica os pares recíprocos. Como o requisito é avisar quem desliza por último na hora, o desenho segue com consistência forte, e a comparação abaixo mostra as opções.

1. O app envia o swipe ao serviço, que monta uma chave única para o par de usuários, na mesma ordem para os dois sentidos.

2. O serviço manda o Redis gravar o swipe e ler o swipe do outro numa operação atômica.

3. Se o outro também curtiu, o match é criado e quem curtiu antes recebe o push.

4. O Cassandra continua como armazenamento durável do histórico, e o Redis guarda só o recente.

04 · PILHA DE PERFIS

Uma pilha rápida, com filtros e distância

A consulta direta ao banco de perfis é lenta, e a busca por localização é a parte mais lenta. A saída é um índice de busca com suporte geoespacial, mantido em dia com o banco transacional por captura de mudanças (CDC).

Outra saída é pré-computar as pilhas em segundo plano e guardá-las em cache. Isso entrega a pilha na hora, mas usuários muito ativos esgotam o cache e a pilha pode ficar obsoleta, isto é, com perfis que deixaram de atender aos filtros.

1. Ao abrir o app, o pedido chega ao serviço de feed.

2. O serviço entrega a pilha pré-computada que está no cache, sem consulta cara.

3. Um job em segundo plano recalcula as pilhas, em geral só para usuários ativos.

4. Quando a pilha está acabando, o serviço consulta o índice de busca para gerar mais perfis em tempo real.

5. A captura de mudanças leva as alterações do banco de perfis ao índice.

Para limitar a obsolescência, a fonte sugere um TTL estrito para o cache e a pré-computação apenas para usuários ativos; mudar filtros ou de lugar também pode disparar uma atualização em segundo plano.

05 · PERFIS JÁ VISTOS

Nunca repetir um perfil

Mostrar de novo um perfil já deslizado passa a impressão de que o swipe se perdeu. A abordagem mais simples consulta o histórico de swipes do usuário e filtra os já vistos. Ela pode perder swipes e reexibir perfis, e fica mais cara conforme o histórico cresce.

Um primeiro reforço é o próprio app guardar os swipes recentes e filtrar a pilha no cliente. Para históricos grandes, a fonte propõe um filtro de Bloom por usuário. Ele pode acusar um perfil como já visto sem ter sido, mas nunca deixa de acusar um que foi, então o custo é esconder alguns perfis para sempre. A taxa de erro é ajustável e ligada ao espaço ocupado.

O custo operacional é manter o filtro atualizado e refazê-lo se o cache cair, o que é fácil de fazer a partir dos swipes, mas caro em escala.