Pessoal,
Como vocês pensariam uma API realmente GRANDE - para “servir” 100 mil usuários por dia, 10 mil requisições por hora etc?
Grato.
Oi @pcobao35,
Quando você diz api “grande” diz considerando apenas o número de usuários mesmo? Ou o número de funcionalidade? Ou volume de dados?
Nao há uma fórmula mágica para isso. Tem muitos fatores e requisitos a serem considerados, que afetariam essa escolha. Teria algo específico em mente?
Não usar session e tornar a resposta da requisição assincrona no back-end são os primeiros cuidados. E claro, ter um bom servidor. No geral, faça teste de stress.
A questão que o @AbelBueno levantou é extremamente importante e deve ser considerada para esta análise.
Veja, 100 mil usuário é diferente de 100 mil acessos/dia, mais diferente ainda que 10 mil requisições simultâneas.
Além disso, você já está definindo parte da arquitetura ao dizer que isso é uma API. O que deixa subentendido que você vai consumir recursos da mesma, através de uma ou mais aplicações.
1 curtida
Oi @AbelBueno,
A ideia é servir à muita gente diariamente, com um grande volume de dados. Não tenho nada específico em mente, mas preciso de algo que “guente o tranco” nos horáios de pico…
Como você faria para, por exemplo, atender a 10.000 requisições por hora (ou algo do tipo)?
Oi @javaflex,
É possível realizar testes de estresse simulando, neste exemplo, 10.000 usuários/requisições?
Oi @darlan_machado,
Exato: a ideia é servir à aplicações com esta API. Por isso a “preocupação” em ter um backend efetivamente “parrudo”. Como você faria?
Isso depende também do perfil das requisições … Não adianta nada você escalar horizontalmente sua API se ela tiver que gravar um BD relacional …