Conteúdo original em https://twitter.com/zanfranceschi/status/1572256034340868097
Ei dev,
Pra você que curte um desafio de System Design, pega esse aqui!
O desafio é melhorar uma integração com muitas falhas com um parceiro; idealmente diminuindo o acoplamento temporal.
Cola mais pros detalhes.
cc @sseraphini
↓
VISÃO GERAL
Esses desenhos mostram um pouco da integração entre DOLLARZ (o serviço do seu time) e COTAÇÃO DO DÓLAR (o serviço de terceiros que oferece a cotação do dólar do dia).
(Pra simplificar o desafio, a premissa é de que o dólar é cotado diariamente apenas.)
Rápida explicação sobre a nomenclatura CACHE MISS (e HIT):
CACHE MISS: é quando a informação não é encontrada no cache, seja pela expiração do item, seja pela aplicação não estar "aquecida".
CACHE HIT: quando a informação é encontrada no cache.
PROBLEMA
O horário do dia em que a cotação muda é instável (pode ser de manhã, de noite, ninguém sabe... esse serviço de cotação do dólar é realmente ruim). O melhor que o seu novo time pôde fazer foi manter um cache de uma hora, mas mesmo assim há muitas falhas (HTTP 500).
Essas falhas refletem no aumento das chances de mostrar a cotação errada do dólar para seus usuários. E isso acarreta em muita operação para correção e frustração dos usuários (as compras com a cotação incorreta são desfeitas).
DESAFIO
Tendo a liberdade total de mudança/criação do seu lado (DOLLARZ), o que poderia ser feito para melhorar a experiência do usuário e diminuir a operação de correções de inconsistências?
PREMISSAS
Nada pode ser alterado no serviço COTAÇÃO DO DÓLAR;
A área de engenharia preza pelo desacoplamento temporal ou, pelo menos, sua diminuição – tente ir nessa linha;
+
- O seu time notou que quando as falhas começam a ocorrer na integração (respondendo com erros HTTP 500), após cerca de 20 requisições, o serviço se restabelece (é, estranho mesmo).
O que DOLLARZ faz realmente não está bem descrito, mas isso não deveria ser um problema pra esse desafio fictício – foque no problema específico da integração. Não existe o jeito certo, não tem pegadinha. É apenas um exercício e faça como quiser!
Seria legal demais se postasse aqui seu desenho da solução.
Se leu até aqui, dá um abraço aqui ó 🫂
Muito obrigado pela moral! ♥️
Top comments (1)
🫂
Não sei se seria a melhor forma, mas como temos um parâmetro para iniciar a solução (após um erro 500 depois de 20 requisições retorna) vejo três maneiras de resolver isso.
Talvez ter um outro serviço de cotação e caso o primeiro falhe, buscar a informação do outro serviço. Nesse caso você teria um backup caso ocorra falhas. Como existem diversas API de cotação de moeda, talvez fosse uma boa saida.
A maneira que poderia ser feito por exemplo é ter uma outra aplicação que roda a cada minuto por exemplo com a responsabilidade apenas de atualizar o cache. Essa aplicação não estará ligado direto ao usuário final. Caso a atualização do cache receba falha, pode ter a rotina para executar as "20 vezes" até deixar de retornar o erro 500.
e por fim seria nesse mesma aplicação, caso a chamada da API receba um erro 500, iniciar uma task paralela que irá fazer as "20 request" na API que ocorre o erro 500.
Agora se fosse um problema real, talvez a solução ideal seria buscar um fornecedor que tenha uma API de cotação melhor rsrs.