Curiosidade. Se você não tem ideia de como fazer isso pensando a nível de Infra não é tão difícil assim lidar com 2K de requisições por segundo 100% sync usando AWS Lambda. Até porque hoje Lambda suporta Go que ajudaria bem e existem recursos pra contornar o Cold Start Basta pagar kk - ThreadSky

samsantosb.bsky.social • 141 days ago

Curiosidade.

Se você não tem ideia de como fazer isso pensando a nível de Infra não é tão difícil assim lidar com 2K de requisições por segundo 100% sync usando AWS Lambda.

Até porque hoje Lambda suporta Go que ajudaria bem e existem recursos pra contornar o Cold Start

Basta pagar kk

Reposted from ✪ Felippe Regazio

duvida para os backenders:

em um sistema de notificações em tempo real pra aguentar inicialmente 2.000 RPM / em média (sim, coisa pra caraleo), vcs fariam tudo já debaixo de um sistema de filas, ou acham que um socket server segura o tranco?

Comments

felipperegazio.com•141 days ago

mas e se eu quiser pagar o mínimo? o que eu poderia fazer?

thiagoaraujo-xd.bsky.social•141 days ago

A fila mesmo, de forma que a fila vai startar a lambda...

felipperegazio.com•141 days ago

então precisa de fila? a diferença é se eu quero pagar ou fazer na unha?

thiagoaraujo-xd.bsky.social•141 days ago

O custo do SQS por exemplo e minimo e vc fazer na mao vai ter de provisionar maquina, entao teria de fazer a conta e por na ponta do lapis. A vantagem de ter um SQS no meio e justamente evitar perda de requests com politica de reentrega.

felipperegazio.com•141 days ago

outra pergunta: usando lambda seguraria bem o fator "real time"? meio que eu não precisaria de um server sent events, socket, polling ou algum evento pra atualizar os clients?

tomazfernandes.dev•141 days ago

Pra esse caso de uso, o supabase tem um esquema de websockets bem legal.

Você assina ele direto do front, e quando um registro é inserido ou alterado você captura o evento e atualiza a tela.

Usa row-level security.

Bem prático!

eduronqui.dev•140 days ago

Mas é uma boa poderia assinar eventos de banco direto no front?

tomazfernandes.dev•140 days ago

É, então, eu sempre diria que não, mas eles tem um esquema legal.

Você configura o acesso dizendo que apenas o usuário “dono” daquele registro tem acesso

Aí pra assinar e receber eventos o user precisa estar autenticado, e só pode receber eventos referentes a si.

tomazfernandes.dev•140 days ago

Usaria isso pra trafegar dados de cartão de crédito? Nunca rs.

Mas pra dados de ex. uma rede social já fica mais sussa.

samsantosb.bsky.social•141 days ago

É se for notificações pro front deve dar pra usar SSE mas teria várias limitações pelo timeout de 15min das Lambdas

fernandocruz.bsky.social•140 days ago

Essa solução seria financeiramente viável? Usar Serverless pra esse propósito não me parece fazer muito sentido.

samsantosb.bsky.social•140 days ago

Seria sim apesar de existirem opções mais baratas que exigem mais dominio de infra

fernandocruz.bsky.social•140 days ago

Na VCMD (minha startup), a gente usava Serverless com SQS, tinha alta escalabilidade, mas a gente tinha picos de uso do App em determinados momentos. Usando Sync e em alta disponibilidade, fiquei na dúvida se o custo seria viável. BTW, um colega sugeriu https://www.gomomento.com

diegoabadan.bsky.social•140 days ago

A Cloudflare faz propaganda que o dela é até 10x mais barato, mas sem exigir domínio de infra. Será que ajudaria?
Nunca utilizei...

https://workers.cloudflare.com/

fabiofa87.bsky.social•141 days ago

Dúvida: pq Go? Pelas rotinas? Fiquei curioso e não faço ideia. Pode dar uma palhinha, com todo respeito?

samsantosb.bsky.social•141 days ago

Porque geralmente o Cold Start de uma Lambda com Go é menor e a linguagem é mais rapida que as outras que temos de opções na Lambda.

Ela tb teria latência reduzida, tempo de invocação reduzido o que afetaria os custos positivamente