Escolha e dimensione um banco de dados

Escolher onde guardar os dados é questão de padrões de acesso e garantias, não de moda. Bancos relacionais (PostgreSQL, MySQL) oferecem transações ACID, joins e um esquema rígido - uma ótima escolha padrão. Bancos NoSQL abrem mão de parte disso em troca de um formato específico: chave-valor (Redis, DynamoDB) para buscas por chave, documentos (MongoDB) para registros aninhados flexíveis, colunas largas (Cassandra) para conjuntos enormes de dados com muita escrita, particionados por chave, e bancos de grafos para percorrer relacionamentos.

Um índice (geralmente uma árvore B) permite que o banco encontre linhas sem varrer a tabela inteira e permite consultas por intervalo, como “posts da última semana”. O custo: mais armazenamento, e toda escrita também precisa atualizar cada índice.

Na replicação líder-seguidor, um líder aceita as escritas e as transmite para os seguidores, que atendem leituras. Isso escala as leituras e acrescenta redundância. Com replicação assíncrona, os seguidores podem ficar atrasados, então uma leitura num seguidor pode devolver dados desatualizados.

Uma solução comum para o atraso é a consistência read-your-writes (ler o que você escreveu): por um curto período depois que um usuário escreve, mande as leituras dele para o líder. O failover promove um seguidor quando o líder cai; com replicação assíncrona, escritas que o antigo líder confirmou, mas ainda não tinha replicado, podem se perder. A replicação multilíder e a sem líder aceitam escritas em vários lugares, ao custo de ter que resolver conflitos.