Get live statistics and analysis of Dev Crítico 🦀's profile on X / Twitter

🧵Caso real de System Design para Staff Engineer - 1/9 💰Salário: R$40K+ CLT 🧩Desafio: Monitorar em tempo real operadores em campo 🏢Empresa: ??? (Brasil) Detalhes do caso e como resolvi?👇

Dev Privilegiado > trampa com stack moderna > produto inovador > recebe bem É muito difícil ter os 3

Conhecimento útil que muitos Devs não desenvolvem? > Redes Mais qual?

REST não é HTTP! > HTTP: protocolo > REST: estilo/modelo arquitetural Essa confusão rola porque REST é normalmente implementado com protocolo HTTP e JSON como formato da mensagem, é o padrão da indústria. O resultado disso, são implementações que apenas usam HTTP como meio, e quase não seguem de fato os princípios REST. Entenda: sua API pode apenas estar usando HTTP como meio de transporte e só.

Conhecimento essencial que vejo muito Dev falhando: Banco de Dados. DB não se escolhe por gosto, DB se escolhe por problema a ser resolvido, cada um vai se encaixar melhor para resolução do seu problema (SQL, NoSQL, colunar, documento, etc). Aprenda sobre sharding, particionamento, CDC, replicação, indexação CORRETA, que reaproveita índices compostos já existentes, cold storage, quando matar um particionamento.

> escolha Postgres como seu RDBMS > fique indisponível por falta de conexões > aprenda o que é um pool de conexões > culpe o Postgres por skill issue

IMO, vivemos o pior momento na história para Dev Jr.

Passei pelo Meli em 2017~2019, foi uma ótima fase na minha vida. O motivo da minha saída foi por buscar experiências que permitissem contato com Cloud, e voltar a usar isso a favor na minha carreira, deu muito certo. Na época o Fury (plataforma interna) já resolvia tudo para os Devs, alguns cliques e você já tinha um projeto com: > stack selecionada (Java, Nods, Go, etc.) > repo configurado no github + pipeline > observabilidade no DD + NewRelic > banco de dados SQL ou NoSQL Key Value ou NoSQL Search Enginee > fila …+

Indícios que você nunca trabalhou com alto volume de dados: 1. Nunca se preocupou com particionamento de tabelas. 2. Nunca se preocupou com sharding. 3. Nunca teve cagaço em criar um índice e ferrar a escrita do seu banco. 4. Nunca cogitou separar a escrita da leitura. 5. O negócio faz queries analíticas direto no banco transacional de prod. 6. Nunca estudou o planner da Query mil vezes antes de promover algo. 7. Nunca cogitou uma view materializada em algum momento.

Sobre Clean Architrcture/Hexagonal Um dos principais argumentos contra é a carga cognitiva: mais camadas = mais peso. O curioso é que, quando você domina, não precisa “lembrar” de tudo, a estrutura vira algo natural pra você. Na real, arquiteturas domain centric não aumentam de forma relevante a carga cognitiva do projeto, ela organiza.

O ElasticSearch ou qualquer outra engine de busca brilham em cenários de full-tech search, PORÉM, é mais indicado para alto volumes de dados, alto TPS, etc. Iniciaria com o PostgreSQL, com um grande ponto de atenção: Se a busca for com LIKE “%…%”, índice Btree não resolve, precisa ser um índice GIN, e índices GIN podem (e vão) ser problemáticos em determinado volume.

TikTok salva 300K USD por ano migrando app de Go pra Rust, melhorando números como: > consumo de CPU: 36% > uso de memória: 72% > latência p99: 76% Meu take sobre esse tema, é que não precisamos mais esperar para ter aplicações Rust como standard na indústria, o ecossistema Web está ficando cada vez mais rico, é inegável as vantagens com relação à segurança e performance by design da stack, e a argumentação de que era complicado escrever código Rust já não é mais válido com o suporte de LLMs, a curva caiu muito.

PÉSSIMO take, mas MUITO PÉSSIMO. Se alguém te questionar em uma entrevista o que fazer nessa situação, NÃO responda isso. Existem VÁRIOS fatores que podem interferir em “lentidão” de queries, e nem sempre se resolve jogando dinheiro no problema, além do fato de muito DBs gerenciados em Cloud (RDS por exemplo), não oferecer scale de recurso vertical em muitas situações sem downtime, e dependendo do que você precisar subir (trocar o tipo de instância por ex), você precisa fazer uma migração de banco. “Aí tá topando CPU, coloca mais 8 core aí” NÃO é assim que funciona… Se seu problema for com IOPS, e você já revisou que suas queries não estão fazendo loucura, estão usando índices de forma correta, existe a opção de separar a leitura para um read replica, RDS Aurora oferece isso out-of-the-box. Revise sua escrita também, índices desnecessários consomem recurso na escrita, e consequentemente impactam a leitura. > NÃO é verdade que “vai ser mais barato”, isso depende da query ofensora, se ela faz varios Joins e tem custo alto de resolução, e é composta por entidades com baixa volatilidade, usar camada de cache PODE ser muito mais barato. É um assunto multifacetado, com diversas causas possíveis…

Básico sobre banco SQL: Subir recurso do seu RDBMS não vai resolver seu problema de lock, modelagem, falta e/ou excesso de índice, etc. > a mesma query que faz seu banco topar CPU por causa de full scan, vai fazer ele topar CPU com mais recurso. > seu problema de lock por transação aberta na aplicação, adivinha? Vai continuar sendo responsável por lockar seu banco após subir recurso também. > seu problema de conexões abertas por causa do pool mal configurado da sua app, adivinha? Vai continuar… E isso nem se aplica a só banco de dados, é pra qualquer coisa: Façam a análise do problema, entender a causa é fundamental. É até meio bizarro falar isso, mas parece que muitos enxergam o banco como uma entidade isolada, que é só apertar um botão que vai passar a escalar… Obs: eu não sou contra subir recurso de banco, sim quando faz sentido…

Netflix WAL Platform WAL (Write Ahead Log) Platform, é uma plataforma de dados que a Netflix construiu como solução comum para problemas conhecidos em sistemas distribuídos: > data loss > escrita (sync) em diferentes datastores (ex: ElasticSearch, Cassandra) > replicação de dados > ...+ Vale a pena a leitura. Obs: não confundir com o WAL do Postgres.

Conhecimento útil que muitos Devs não desenvolvem? > Redes Mais qual?

Dev Privilegiado > trampa com stack moderna > produto inovador > recebe bem É muito difícil ter os 3

🧵Caso real de System Design para Staff Engineer - 1/9 💰Salário: R$40K+ CLT 🧩Desafio: Monitorar em tempo real operadores em campo 🏢Empresa: ??? (Brasil) Detalhes do caso e como resolvi?👇

TikTok salva 300K USD por ano migrando app de Go pra Rust, melhorando números como: > consumo de CPU: 36% > uso de memória: 72% > latência p99: 76% Meu take sobre esse tema, é que não precisamos mais esperar para ter aplicações Rust como standard na indústria, o ecossistema Web está ficando cada vez mais rico, é inegável as vantagens com relação à segurança e performance by design da stack, e a argumentação de que era complicado escrever código Rust já não é mais válido com o suporte de LLMs, a curva caiu muito.

IMO, vivemos o pior momento na história para Dev Jr.

Sobre Clean Architrcture/Hexagonal Um dos principais argumentos contra é a carga cognitiva: mais camadas = mais peso. O curioso é que, quando você domina, não precisa “lembrar” de tudo, a estrutura vira algo natural pra você. Na real, arquiteturas domain centric não aumentam de forma relevante a carga cognitiva do projeto, ela organiza.

> escolha Postgres como seu RDBMS > fique indisponível por falta de conexões > aprenda o que é um pool de conexões > culpe o Postgres por skill issue

O ElasticSearch ou qualquer outra engine de busca brilham em cenários de full-tech search, PORÉM, é mais indicado para alto volumes de dados, alto TPS, etc. Iniciaria com o PostgreSQL, com um grande ponto de atenção: Se a busca for com LIKE “%…%”, índice Btree não resolve, precisa ser um índice GIN, e índices GIN podem (e vão) ser problemáticos em determinado volume.

REST não é HTTP! > HTTP: protocolo > REST: estilo/modelo arquitetural Essa confusão rola porque REST é normalmente implementado com protocolo HTTP e JSON como formato da mensagem, é o padrão da indústria. O resultado disso, são implementações que apenas usam HTTP como meio, e quase não seguem de fato os princípios REST. Entenda: sua API pode apenas estar usando HTTP como meio de transporte e só.

Conhecimento essencial que vejo muito Dev falhando: Banco de Dados. DB não se escolhe por gosto, DB se escolhe por problema a ser resolvido, cada um vai se encaixar melhor para resolução do seu problema (SQL, NoSQL, colunar, documento, etc). Aprenda sobre sharding, particionamento, CDC, replicação, indexação CORRETA, que reaproveita índices compostos já existentes, cold storage, quando matar um particionamento.

Passei pelo Meli em 2017~2019, foi uma ótima fase na minha vida. O motivo da minha saída foi por buscar experiências que permitissem contato com Cloud, e voltar a usar isso a favor na minha carreira, deu muito certo. Na época o Fury (plataforma interna) já resolvia tudo para os Devs, alguns cliques e você já tinha um projeto com: > stack selecionada (Java, Nods, Go, etc.) > repo configurado no github + pipeline > observabilidade no DD + NewRelic > banco de dados SQL ou NoSQL Key Value ou NoSQL Search Enginee > fila …+

Indícios que você nunca trabalhou com alto volume de dados: 1. Nunca se preocupou com particionamento de tabelas. 2. Nunca se preocupou com sharding. 3. Nunca teve cagaço em criar um índice e ferrar a escrita do seu banco. 4. Nunca cogitou separar a escrita da leitura. 5. O negócio faz queries analíticas direto no banco transacional de prod. 6. Nunca estudou o planner da Query mil vezes antes de promover algo. 7. Nunca cogitou uma view materializada em algum momento.

PÉSSIMO take, mas MUITO PÉSSIMO. Se alguém te questionar em uma entrevista o que fazer nessa situação, NÃO responda isso. Existem VÁRIOS fatores que podem interferir em “lentidão” de queries, e nem sempre se resolve jogando dinheiro no problema, além do fato de muito DBs gerenciados em Cloud (RDS por exemplo), não oferecer scale de recurso vertical em muitas situações sem downtime, e dependendo do que você precisar subir (trocar o tipo de instância por ex), você precisa fazer uma migração de banco. “Aí tá topando CPU, coloca mais 8 core aí” NÃO é assim que funciona… Se seu problema for com IOPS, e você já revisou que suas queries não estão fazendo loucura, estão usando índices de forma correta, existe a opção de separar a leitura para um read replica, RDS Aurora oferece isso out-of-the-box. Revise sua escrita também, índices desnecessários consomem recurso na escrita, e consequentemente impactam a leitura. > NÃO é verdade que “vai ser mais barato”, isso depende da query ofensora, se ela faz varios Joins e tem custo alto de resolução, e é composta por entidades com baixa volatilidade, usar camada de cache PODE ser muito mais barato. É um assunto multifacetado, com diversas causas possíveis…

Muito código vem sendo reescrito em Rust por inúmeros motivos de performance e segurança by design (nem preciso entrar em detalhes), isso por si só já é motivo para incomodar muitas bolhas. Resistência à mudança é natural, mas insistir em não mudar é burrice. Se você não entende o motivacional da adoção do Rust, ou você está ficando pra trás, ou você é negacionista.

NoSQL não é sinônimo de flexibilidade para tudo! Galera, quando estamos falando de NoSQL, não estamos falando apenas de MongoDB, há diversos bancos NoSQL que melhor resolvem um tipo de problema, um determinado use case. Existem document based, column based, search engine, existem bancos mais voltados para o transacional (OLTP), outros mais voltados para o analítico (OLAP), etc. AS VEZES, um document based melhor resolve um use case, principalmente em situação onde há alta volatilidade das propriedades e serem persistidas, simplesmente porque você não precisa alterar um schema, um DDL, fazer uma migration sempre que passar a persistir uma prop nova e lockar seu banco de dados enquanto isso, o mesmo não é verdade para um ElasticSearch por exemplo, que também é NoSQL, mas tem um propósito totalmente diferente. Eu tenho a sensação que há uma confusão enorme em NoSQL e MongoDB. Mongo não é o único NoSQL que existe.