Rastreador de preços (CamelCamelCamel)

01 · CONTEXTO

O que o rastreador precisa fazer

O CamelCamelCamel é um serviço que acompanha os preços de produtos da Amazon ao longo do tempo e avisa a pessoa quando o preço cai abaixo do limite que ela definiu. A fonte descreve também uma extensão de navegador popular, com um milhão de usuários ativos, que mostra o histórico dentro da página do produto e permite assinar o aviso com um clique.

Os requisitos funcionais centrais são dois: ver o histórico de preços de um produto e assinar avisos de queda com um limite. Os dois precisam funcionar pelo site e pela extensão. Este é um bom exercício de levantamento de requisitos.

Ficam fora do escopo a busca e descoberta de produtos na plataforma, a comparação de preços entre varejistas e a integração de avaliações e notas.

02 · REQUISITOS NÃO FUNCIONAIS

Escala, latência e ser educado com a Amazon

A fonte fixa quatro metas: priorizar disponibilidade sobre consistência, aceitando consistência eventual; lidar com 500 milhões de produtos da Amazon; responder consultas de histórico em menos de 500 ms; e entregar avisos de queda em até 1 hora depois da mudança de preço.

A fonte resume a tensão do problema numa frase: o sistema precisa ser educado com a Amazon e, ao mesmo tempo, entregar rastreamento de preços útil a milhões de usuários.

03 · DESENHO DE ALTO NÍVEL

Do histórico à assinatura

Uma proposta de alto nível separa três caminhos: ler o histórico, registrar a assinatura e coletar preços. Os dados de preço formam uma série no tempo, o que combina com o tópico de séries temporais. A coleta roda de forma assíncrona em relação às consultas dos usuários, com pipeline de dados e filas de mensagens.

1. No desenho proposto, o site e a extensão falam com a mesma API, que encaminha cada pedido ao serviço certo.

2. A leitura do histórico passa pelo serviço de histórico, que consulta o armazenamento de séries de preço.

3. A assinatura segue outro caminho: o serviço de assinaturas grava o limite escolhido num banco relacional.

4. A coleta é um caminho à parte: o agendador coloca pedidos na fila e os coletores os consomem.

5. Cada coletor consulta a fonte externa e grava o preço observado no histórico, sem passar pelas consultas dos usuários.

04 · APROFUNDAMENTOS

As quatro perguntas difíceis

A página pública lista quatro aprofundamentos: como descobrir e rastrear 500 milhões de produtos de forma eficiente; como lidar com atualizações de preço potencialmente maliciosas vindas de usuários da extensão; como processar mudanças de preço e avisar os inscritos; e como servir consultas rápidas de histórico para gerar gráficos.

O texto completo da fonte, com as respostas, exige assinatura Premium. Por isso, o restante deste caso trata as quatro perguntas como raciocínio de estudo e não atribui soluções à fonte.

05 · RACIOCÍNIO

Como atacar cada pergunta

Cobertura e ritmo de coleta: para varrer um catálogo enorme sem sobrecarregar a origem, o agendador decide quais produtos verificar e com que frequência, e os coletores limitam o ritmo de pedidos. Produtos com muitas assinaturas ou preço volátil podem ser verificados com mais frequência do que os pouco procurados.

Relatos da extensão: um preço reportado por um usuário é um dado de origem não confiável. Uma abordagem é tratá-lo como sinal, comparando-o com a coleta própria e com relatos de outros usuários antes de gravá-lo como observação.

1. O cliente pede o histórico de um produto pela API.

2. O serviço de histórico olha primeiro no cache de séries já montadas.

3. Quando a série não está no cache, o serviço a lê do armazenamento de preços.

4. Um preço reportado pela extensão passa pelo validador antes de chegar ao armazenamento.

Avisos: cada mudança de preço gravada vira um evento; avaliadores comparam o novo preço com os limites cadastrados e pedem o envio por uma fila separada. Esse desenho usa o padrão de filas de mensagens.

1. Cada preço novo gravado no histórico vira um evento de mudança numa fila.

2. O avaliador de limites consome o evento de mudança.

3. Para decidir, o avaliador consulta as assinaturas e os limites do produto.

4. Quando um limite é atingido, o pedido de aviso segue por uma fila própria até o enviador e chega ao usuário.