DEV Community: Breno Ferreira

Testes de UI com Testing Library

Breno Ferreira — Mon, 03 Aug 2020 11:50:41 +0000

Aviso: isso não é um tutorial

Acho que qualquer dev com alguns anos de experiência em desenvolvimento web, em algum momento, teve que fazer testes de interface.

Algumas ferramentas bem comuns para esses tipos de testes são Selenium (e outros parecidos como Cypress por exemplo) que são focados no que chamamos de end-to-end tests, que possuem uma API de automatização do browser para simular o uso da página. Eu particularmente não gosto desses testes pois são geralmente muito frágeis. Como são testes de mega-integração do sistema, Além deles serem muito lentos, qualquer módulo do sistema não respondendo perfeitamente pode causar uma falha do teste. Então o desenvolvedor acaba não rodando esses testes na própria máquina, rodando-o somente no servidor de CI. Quando algum teste falha no CI (e certamente vai falhar com bastante frequência), é mais dificil debugar remotamente. Então o dev roda na sua máquina, e surpresa: works on my machine! Essa inconsistência e fragilidade acaba inevitavelmente no time decidindo não manter mais esses testes. Já vi isso acontecendo trocentas mil vezes.

Hoje em dia, as libs de frontend modernas, seja React, Angular, Vue, etc., possuem um framework para testar componentes. Não importa qual lib voce escolha, testar seus componentes vai ajudar a garantir que sua UI está funcionando adequadamente. Arriscaria dizer que se voce tem bons testes de unidade no frontend e bons testes de unidade e integração no backend, vai ser suficiente para garantir o mínimo de qualidade e confiabilidade para deploys frequentes e tranquilos. Aqueles testes end-to-end com Selenium ou outra ferramenta qualquer se tornarão desnecessários e não vão ajudar (muito) a identificar bugs mais complexos. Mas enfim, isso é assunto pra outro post. Voltemos aos testes de componentes.

A maioria dessas libs de teste funciona da seguinte forma: o componente o HTML e alguma lógica de interação, e no teste utiliza-se funções para fazer asserções sobre esse markup e lógica, geralmente utilizando selectors. Por exemplo (com React):

const Produto = ({ produto }) => (
 <div class="produto">
  <span class="produto-nome">{produto.nome}</span>
  <span class="produto-descricao">{produto.descricao}</span>
  <span class="produto-preco">R${produto.preco}</span>
 </div>
)

Estou usando React aqui como exemplo, mas com Vue ou Angular não é muito diferente.

describe('Componente Produto', () => {
 it('exibe preço do produto', () => {
  const produto = { nome: 'TV', descricao: 'TV 4k', preco: 2000 };
  const component = render(<Produto produto={produto} />)

  const preco = ReactTestUtils.findRenderedDOMComponentWithClass(componente, 'produto-preco');

  expect(preco.textContent).toBe('R$ 2000');
 });
})

É um exemplo simples, e que funciona razoavelmente bem. Porém, tem um problema nesse teste e que é comum à praticamente todos os frameworks de teste de interface, que é utilizar selectors, no exemplo, class selectors. Esses frameworks forçam o teste a fazer queries no markup via selectors, seja por class, id ou tag html.

Isso causa um certo acoplamento do teste com a implementação. Se voce muda o HTML da página, seu teste quebra, mesmo que o conteúdo em si tenha se mantido. No exemplo acima do produto, se por acaso eu tiver que mudar o nome da classe para outra coisa por alguma necessidade de CSS, isso vai quebrar todos os testes daquele componente sem nenhuma necessidade, pois a funcionalidade não mudou, o que mudou foram detalhes visuais.

Testing Library

O Testing Library tem uma filosofia e abordagem bem diferente nos testes. Sua API não possui uma função para obter um elemento via class, id nem tag. Sua API é voltada ao conteúdo do componente. Reescrevendo o teste acima, ele ficaria da seguinte forma:

describe('Componente Produto', () => {
 it('exibe preço do produto', () => {
  const produto = { nome: 'TV', descricao: 'TV 4k', preco: 2000 };
  const componente = render(<Produto produto={produto} />)
  expect(componente.getByText('R$ 2000')).toBeInTheDocument();
 });
})

Repare que em momento algum eu fiz uma consulta de selector. O teste simplesmente verifica se o componente está renderizando o preço corretamente. Se o HTML mudar, mas o preço continuar lá, o teste não quebra, como deveria ser.

O Testing-Library tem diferentes funções de consultas, definidas da seguinte forma: getBy*, getAllBy*, queryBy*, queryAllBy*, findBy* e findAllBy*. E existem funções com "sufixos" variados para diferentes tipos de consulta.

No caso de formulários, as funções de consulta disponíveis são por: texto do label *ByLabelText, texto do placeholder do input *ByPlaceholderText, e pelo value do input *ByDisplayValue.

No caso de texto livre, existe o *ByText.

Para imagens, existe o*ByAltText. E existem outras queries mais genéricas como o *ByTitle, para elementos que possuem o atributo title, *ByRole para consultar elementos por aria-role. Essas funções inclusive podem ajudar os testes a guiarem à um HTML mais acessível.

Existe também o *ByTestId que te possibilita fazer consultas à elementos com um atributo data-testid, porém é preferível usar os outros métodos de consulta e deixar o uso dessa função para casos onde fica muito difícil usar as outras funções dificulta muito o teste.

A documentação das queries explica com mais detalhes como cada uma funciona.

É possível ver que o framework vai te forçar a escrever seus testes de maneira bem diferente, sempre direcionados ao conteúdo da página, e não à detalhes de implementação do HTML. Também acho que deu para notar que essa abordagem possibilita ter testes menos acoplados à implementação e assim bem mais resistentes à mudanças. Além disso, a lib possui implementação para quase todos os frameworks frontend mais conhecidos: React, Angular, Vue entre outros. Isso ajuda em casos de projetos usando libs diferentes à terem uma suite de testes mais uniforme e não obrigar as pessoas a aprenderem uma API de testes para cada framework.

Dados distribuídos — Particionamento/Sharding

Breno Ferreira — Mon, 27 Jul 2020 14:46:37 +0000

Parte da série sobre o resumo do livro Designing Data Intensive Apps.

Até aqui, falamos sobre alguns temas gerais sobre bancos de dados: Sistemas de dados, Modelos de Dados, Armazenamento de Dados, Serialização de Dados e Replicação de Dados.

Uma outra técnica que pode ser utilizado para aumentar a escalabilidade do banco de dados é particionamento (ou também conhecido como sharding) de dados que pode ser aplicado em conjuntos de dados muito grandes com com um volume de queries muito alto.

Como particionar os dados?

Uma parte mais dificil de particionar dados é: como particionar? Existem técnicas diferentes, algumas funcionam melhores que outras.

Técnicas mais ingênuas de particionamento costumam causar hot-spots em algumas partições, ou seja, um número muito alto de acessos à uma única partição enquanto as outras estão paradas. Por exemplo:

Numa rede social, particionar por username. Entao, cada partição armazenaria dados de usuarios com username começando de A à C, de D à F, etc..

No Instagram por exemplo, os usuários com mais seguidores estão distribuídos da seguinte forma:

Dá pra perceber que nesse caso a primeira partição seria um hot spot, pois 2 dos 3 usuarios com mais seguidores tem seu username começando com A, B ou C (Ariana Grande e Cristiano Ronaldo), além de Beyonce em 9 lugar. Todos com centenas de milhões de seguidores. Olhando o ranking dá pra perceber que usuários com +100 milhões de usuários tem as iniciais mais comuns T, K, J, N.

Outro exemplo: particionar por data. Digamos que dados escritos num dia são escritos em partições diferentes. Caso haja um volume muito alto de escrita, em cada dia uma partição será o hotspot, enquanto as outras só irão atender à requisições de leitura.

Consistent Hashing Partitioning

Uma técnica que ajuda a diminuir (mas não eliminar) esses hotspots é particionar por um hash. No exemplo da rede social, voce pode calcular um hash do username e armazenar em alguma partição. Esses hashes devem ser distribuídos uniformemente entre as partições.

Particionar por hash ainda não elimina hotspots. Por exemplo a partição onde os dados do Cristiano Ronaldo estão armazenados vai continuar sendo muito acessada. Mas assim voce consegue distribuir melhor os dados e a carga.

Problemas com particionamento

Claro que os problemas não iriam acabar aí.

No caso de bancos de dados relacionais, joins agora podem potencialmente ser distribuídos em varios nós, consequentemente, bem menos eficientes. Por isso saber escolher bem sua estratégia de particionamento é importante.

Outro problema ocorre com índices secundários. No caso do índice primário no hash da chave, os dados estão na mesma partição, então não costuma ser muito problemático. Mas em um índice secundário os dados provavelmente vão estar em partições diferentes. Por exemplo: armazenando dados de livros, voce particiona pelo hash do código ISBN, mas com certeza vai precisar também de um índice secundário no título dos livros para buscas eficientes. Então, os livros sobre "Computação Distribuída" não vão estar necessariamente na mesma partição.

Índice secundário local

Uma estratégia é cada partição manter seus índices secundários para os seus próprios dados. Então, quando um cliente executa uma consulta, é necessario consultar os índices de cada partição, numa operação conhecida como scatter/gather. Essas consultas geralmente costumam ser bem lentas.

Índice secundário global

Outra estratégia é criar um índice global particionado. No exemplo de livros, o termo "Computação" estaria no índice na partição 1, enquanto o termo "Medicina" estaria no índice na partição 3. Os dados em si podem estar em outras partições, mas ao contrário do índice local por partição, não é necessário fazer uma busca em todas as partições, pois o índice por termo garante que voce encontra todos os documentos associados àquele termo e buscar diretamente nas partições que contêm os dados, melhorando a performance de consulta. O problema com essa estratégia é que a performance de escrita é ruim, pois esse índice distribuído precisa ser atualizado à cada escrita. Essa atualização geralmente é feita de maneira assíncrona, então ela sofre com o Lag de Replicação que foi abordado no post anterior. Manter um índice distribuído fortemente consistente requer uma transação distribuída, que é bem custosa.

Dados distribuídos - Replicação de dados

Breno Ferreira — Tue, 07 Jul 2020 22:21:02 +0000

Parte da série sobre o resumo do livro Designing Data Intensive Apps.

Até aqui, falamos sobre alguns temas gerais sobre bancos de dados: Sistemas de dados, Modelos de Dados, Armazenamento de Dadose Serialização de Dados.

Agora, é hora de começarmos a falar sobre dados distribuídos e quais são os desafios inerentes à essa prática. Quando queremos garantir escalabilidade e confiabilidade do nosso sistema, é inevitável que em algum momento, nossos dados estejam distribuídos em mais de um lugar. Caso contrário, basta uma falha de acesso ao servidor de banco de dados e a aplicação para de funcionar. Se isso for inaceitável para seu negócio, aceite o fato de que algum nivel de computação distribuída vai existir.

Em uma arquitetura web típica, é comum ter um cluster de servidores web respondendo à requisições e um proxy reverso que as distribui aos nós do cluster. Essa arquitetura é fácil de implementar por que os nós do cluster não compartilham nada entre si (Shared Nothing Architecture). Como servidores web também não armazenam estado (chamados stateless web servers), caso um nó do cluster falhe, basta tirá-lo do cluster, enviar as requisições para os nós que ainda funcionam e adicionar um nó novo. Ter escalabilidade horizontal assim não é dificil.

Em um cluster de banco de dados, ainda é possível usar essa Shared-Nothing Architecture, ou seja, não compartilhamos nenhum recurso computacional. Porém, vai ser inevitável compartilhar uma coisa nos nós do cluster de banco de dados: os dados. Podemos distribuir os dados em vários servidores de um cluster de duas formas: Replicação e Particionamento. Repare que essas técnicas não são exclusivas. Pode haver dados particionados e replicados ao mesmo tempo. Nesse post iremos abordar o tema de replicação de dados. Particionamento de dados fica para um próximo post.

Implementar replicação de dados não é uma tarefa trivial que envolve alguns desafios e que existem algumas estratégias já conhecidas para resolver os problemas que podem aparecer.

Estratégias de replicação de dados

Toda vez que algum dado é escrito no banco, é necessário ter uma cópia desses dados nas outras réplicas do banco. Um cliente que envia uma requisição de escrita (ex: INSERT, UPDATE ou DELETE) para algum nó no cluster, o cluster deve seguir alguma estratégia para replicar esse dado escrito nos outros nós. As estratégias mais comuns de replicação são: Replicação com líder único, Replicação com múltiplos líderes e replicação sem líder.

Replicação de líder único

A estratégia mais comum para se garantir disponibilidade em caso de falha. Nessa estratégia, o cluster sempre elege um líder que será o único responsável por aceitar requisições de escrita. Requisições de leitura são aceitas por qualquer nó, líder ou réplica.

Em uma operação de escrita, o nó líder commita a escrita e envia uma resposta ao cliente. Em seguida, de maneira assíncrona, é enviado aos nós replicas a mesma operação para que o mesmo dado seja escrito nos outros nós e manter todas as réplicas consistentes.

A escrita nas réplicas também pode ser feita de maneira síncrona, com o cliente recebendo a resposta da requisição somente depois da escrita ter sido replicada em todos os nós. Isso evita alguns problemas que veremos depois, mas a performance é bem ruim e pode causar um enorme gargalo caso escritas sejam muito frequentes e principalmente se algum dos nós falhar. É mais comum que se a replicação for síncrona, que apenas um dos nós seja replicado sincronamente e os outros de forma assíncrona.

O líder é eleito pelo cluster usando algum tipo de algoritmo de consenso como Paxosou Raft.

Replicação com múltiplos líderes

Essa é uma estratégia mais comum em ambientes multi-datacenter. Por exemplo, caso exista versões da aplicação rodando em mais de um datacenter diferente, para acesso mais rápido em diferentes regiões (Latam e América do Norte por exemplo). É possível ter um cluster em multiplas regiões e ter um líder por região. Os líderes que commitou o dado replica a operação de escrita com os líderes das outras regiões, que por sua vez, enviam os dados para seus respectivos nós replicas.

Replicação sem líder

Nesse caso o cliente envia a requisição para varios nós. Como não há um líder coordenando que garante a escrita dos dados e a replicação dos dados escritos no banco, é necessário utilizar uma técnica chamada Quorum, que consiste basicamente em ter confirmação de uma maioria dos nós no cluster. Uma operação em um cluster com N nós, para ser considerada bem sucedida, deve ser confirmada por no mínimo K nós. O número K é o que chamamos de Quorum. Esse número K pode ser diferente para operações de leitura e escrita, ou ser igual para ambas operações, desde que esse número satisfaça a seguinte condição:

K_leitura + K_escrita > N

Voce pode definir o valor de K como sendo (N + 1) / 2, arredondado para cima. Então caso haja 4 nós no cluster, as operações teriam que ser confirmadas por um Quorum de ao menos 3 nós.

Esse tipo de replicação sem lider é conhecido como Dynamo-Style Replication. Não confundir com o Amazon DynamoDB que usa replicação com líder único

Desafios

A partir do momento que voce tem mais de uma instancia do seu servidor de banco de dados rodando, diga adeus aos confortos da computação monolítica e abrace a dor e sofrimento da computação distribuída.

Os maiores problemas que costumam aparecer quando há mais de uma réplica dos dados são relacionados a consistência dos dados e, no caso de estratégias com líder, uma falha e recuperação do líder.

Recuperação de falha de um líder se dá da seguinte forma:

Detectar uma falha do líder: Geralmente detecta-se uma falha quando o servidor para de responder e ocorrem timouts. Uma falha pode acontecer por diversas razões como crash do sistema ou falta de energia por exemplo. Em alguns casos o servidor não falhou, mas houve falha da rede e ele fica incomunicável por um tempo. É impossível saber na hora qual a razão da falha, somente que ela ocorreu. Por essa razão, definir um valor de timeout pode ser um pouco complicado. Um timeout muito curto pode causar failovers desnecessários, e um timeout muito longo pode causar um tempo maior para recuperar o sistema de uma falha.
Escolha de um novo líder: Para eleger um novo líder, usa-se algum algoritmo de consenso distribuído como Paxos ou Raft para que todos os nós entrem em acordo sobre qual dos nós réplicas irá tornar-se o novo líder.
Reconfigurar o sistema e passar a usar o novo líder: os clientes agora precisarão se comunicar com o novo líder eleito. Caso o antigo líder volte a funcionar, ele deve detectar a existencia desse novo líder e passar a funcionar como uma réplica, caso contrário pode acontecer o que chamamos de split-brain e isso pode causar conflitos e corrupção dos dados.

Outro problema com dados distribuídos é na consistência dos dados. Como a replicação dos dados não é imediata, e os clientes lêem os dados de réplicas que podem ainda não ter os dados mais atuais que foram escritos pelo líder, pode ser bem comum haver o que chamamos de atraso de replicação, ou Replication Lag.

No exemplo da imagem acima, o usuário faz um INSERT de um dado e o líder envia as requisições de replicação. Como qualquer requisição de rede, uma pode ser mais rápida que a outra, com menor latencia e tempo de resposta menor, então a requisição de replicação no nó Replica 1 é mais rápida do que no nó réplica 2. Porém, o cliente tenta ler o dado que acabou de ser inserido enviando uma requisição para a Réplica 2 (já que leituras podem ser feitas em qualquer nó), porém a requisição chega antes da Replica 2 receber a requisição de replicação do insert, e logo, ela ainda não tem o dado e envia uma resposta com zero resultados.

Uma possível solução para esse problema é ter um controle mais fino sobre a conexão do cliente com o banco de dados para garantir que, quando o cliente ler algum dado que ele próprio tiver escrito, realizar requisição de leitura com o líder e não com réplicas. Essa técnica é conhecida como Read Your Own Writes. Isso garante que pelo menos o usuário vai ler o que ele mesmo escreveu, mas a leitura não é garantida para outros usuários. Por exemplo: em uma rede social, o usuário consegue ler seus próprios comentários, mas pode haver algumas eventuais inconsistências com os comentários dos outros.

Outro problema pode acontecer é Usuario 1 inserir um valor, e o Usuário 2 ter leituras inconsistentes por causa de conexão com réplicas diferentes que ainda não estão 100% consistentes. No caso acima, um cliente 1 insere um valor e esse dado é replicado. O cliente 2 então tenta ler o dado escrito em uma réplica que já teve esse dado replicado em sua base e retorna o valor. Num momento seguinte, o mesmo cliente tenta ler o dado de novo, mas dessa vez em uma réplica que ainda não tem o valor replicado, então ela responde um resultado vazio. Isso pode causar confusão pro usuário pois uma hora ele vê uma coisa, e logo depois não vê mais.

Monotonic Reads é uma garantia que o banco de dados pode prover para que esse tipo de anomalia não ocorra. Ela garante que o usuário ao ler um dado x no tempo t, continuará lendo esse dado no futuro e não lerá uma versão antiga de x em tempo t1. Uma possível implementação pode ser definir a replica de conexão baseado no ID do usuario. Assim, o cliente conecta sempre na mesma réplica. Caso a replica caia, a requisição é redirecionada para outra réplica.

Ambientes de replicação sem líder são otimizados para aplicações com uma tolerância maior à consistência eventual, pois a probabilidade de valores desatualizados é maior (pois não há um líder como uma fonte de consistência). Garantia de consistência geralmente requer transações distribuídas ou algoritmos de consenso distribuído, que são operações com custo alto de performance.

Em casos de falha de algum nó, após ele voltar a funcionar ele deve receber os dados que foram perdidos enquanto ele estava fora do ar. Isso pode acontecer de duas maneiras:

Read repair: o cliente, quando faz uma requisição de leitura pra varios nós, caso receba um valor desatualizado de um nó, envia uma requisição de atualização para o nó que enviou o dado desatualizado.

Processo anti-entropia: um processo que fica continuamente monitorando dados inconsistentes e realiza as atualizações necessárias copiando dados de uma réplica pra outra.

Outro problema que pode ocorrer também é quando, em cenários multi-líder ou sem líder, há escritas concorrentes e é necessário detectar e corrigir dados conflitantes.

Uma estratégia é o que é chamado de Última Escrita Vence (Last Write Wins). Porém, como veremos em posts futuros, determinar ordem de eventos no tempo em ambientes distribuídos não é tão simples. Então pode acontecer de decidir-se por um dado que não é o mais recente, ou até mesmo detectar eventos concorrentes quando na verdade não há concorrencia, mas sim problemas com relógios distribuídos.

Nas linhas de pesquisa mais recentes sobre resolução de conflitos existem alguns algoritmos que permitem uma resolução mais inteligente e automática: Conflict-free replicated datatypes (CRDTs),
Mergeable Persistent Data Structures e
Operational Transformations.

Encoding e Dataflow

Breno Ferreira — Wed, 24 Jun 2020 18:58:04 +0000

Parte da série sobre o resumo do livro Designing Data Intensive Apps.

No Capítulo 1 foi falado sobre características de sistemas de dados, no Capítulo 2 sobre modelos de dados. No Capítulo 3, sobre o tema de armazenamento de dados. Agora iremos abordar o tema de encoding de dados.

O banco de dados, como qualquer aplicação, escreve e lê dados. Escreve dados em memória e disco, e lê esses dados e os envia pela rede para clientes remotos. Em memória, esses dados ficam em estruturas de dados como Hashmaps e/ou Árvores. Porém, tanto no processo de escrita em disco quanto no processo de envio desses dados para os clientes remotos, é necessário converter esses dados em memória para algum formato mais apropriado, num processo conhecido como encoding. Quem lê esses dados por sua vez faz o decoding para converter novamente em alguma estrutura em memória (não necessariamente a mesma estrutura original, podendo ser, por exemplo, uma simples lista ao invés de uma árvore).

Esse encoding/decoding (também chamado de serialização) pode ser feito de várias formas, e existem vários formatos que podem ser usados.

Muitas linguagens de programação possuem seu próprio mecanismo de encode/decode de dados, como as classes java.io.Serializable. Porém não é recomendado usar essas bibliotecas pois não são compatíveis com outros ambientes. Então se um código Java serializa os dados usando a biblioteca nativa do Java e envia para uma aplicação rodando em Python, os dados provavelmente não vão poder ser deserializados. Por isso precisamos usar formatos padrões que qualquer linguagem e ambiente de programação entenda e consiga ler e escrever.

Alguns dos formatos mais comuns são: CSV, XML e JSON que são formatos de texto e legíveis tanto por pessoas quanto por máquinas. Thrift e Protocol Buffers (ProtoBuf) são formatos de serialização binária, logo, legíveis somente por máquinas. Existe também o format Avro, que usa JSON para definição de Schema mas serializa os dados de forma binária. Recomendo ler a documentação de como esses formatos funcionam para definição de Schemas e serialização antes de continuar a leitura.

Destes formatos, o único que não possui uma linguagem para definição de schema é CSV. Por isso é comum dados serializados nesse formato contarem com uma documentação complementar para definição dos tipos de dados. Ou simplesmente deixarem por conta de quem lê os dados a tarefa de interpretar os tipos utilizados. Porém, isso não é muito recomendável.

Tanto JSON quanto XML contam com ferramentas para definição de schemas (XML Schema e JSON Schema), apesar de também ser razoavelmente comum dados transmitidos em formato JSON não terem também disponíveis um JSON Schema associado e contarem mais com documentação suplementar.

Dados serializados de forma binária porém, sem um schema, são somente uma sequencia aparentemente aleatória de bytes. Thrift, ProtoBuf e Avro todos tem suas definições próprias de schema.

Evolução de Schema

Os dados vão inevitavelmente mudar com o tempo. Com mudança nos dados, obviamente o schema também muda. Nessas mudanças de schema, devemos nos preocupar com compatibilidade:

backward compatibility: código novo consegue ler dados antigos
forward compatibility: código antigo consegue ler dados novos

Não mude seu schema com campos novos obrigatórios, mas sim opcionais. Assim, um código que desconhece o schema mais atualizado ainda consegue manipular os dados, pois os novos campos podem conter um valor padrão (0, uma string vazia ou NULL por exemplo).

Caso use formatos binários como Thrift ou ProtoBuf, que fazem o encoding dos dados em uma ordem definida no schema, essa ordem deverá ser mantida.

Mudanças de tipos de dados podem ser complicadas. Em alguns casos, pode ser que um tipo seja automaticamente convertido durante leitura ou escrita (ex: converter um int de 32bits para um int de 64bits, mas não o contrário). ProtoBuf permite também que valores opcionais sejam convertidos para um array de valores, pois na sequencia de bytes final um valor opcional e um array vazio são serializados da mesma forma, e durante deserialização, código que ainda acha que o dado é um valor opcional pode ler somente o último elemento da lista.

Fluxo de dados

Aplicações uma hora vão ter que ler os dados do banco e, em alguns casos, serializar esses dados e enviar para outra aplicação. Por isso devemos entender esses formatos de serialização, evolução de schema e manutenção de compatibilidade.

Fluxo de dados via Banco de Dados

É comum aplicações diferentes acessarem o mesmo banco de dados. E nem sempre precisa ser aplicação X e Y. Pode ser aplicação X v1.0 e aplicação X v2.0 rodando ao mesmo tempo, como por exemplo para manter versões antigas de uma API web funcionando, ou durante um rolling upgrade, onde é feito de forma gradual o deploy de versões novas nos nós do cluster da aplicação e duas versões coexistem por um tempo.

Por isso é importante se preocupar com a evolução do schema de dados para que uma schema migration quebre a compatibilidade entre as versões diferentes das aplicações que acessam o banco de dados. Durante schema migrations também é importante se preocupar como isso irá impactar a disponibilidade do servidor do banco de dados. Adicionar campos novos opcionais, novas tabelas ou views geralmente é bem rápido e não tem muito impacto. Já mudança de tipos de dados pode impactar a disponibilidade do servidor pois terá que ser feita a conversão ou re-escrita de todos os dados na tabela.

Fluxo de dados via serviços REST ou RPC

Não vou entrar nos detalhes técnicos de cada um dos estilos de comunicação, até por que cada um é bem complexo por si só. Mas alguns pontos de atenção ao transmitir dados com esses diferentes tipos de serviços:

REST

Geralmente serviços REST usam XML ou JSON como formato de encoding de dados. Então é importante ficar atento a como manter compatibilidade com esses formatos de dados.

Um ponto interessante é tentar manter um schema para os dados, usando XML Schema ou JSON Schema. Muitas APIs REST que usam esses formatos não possuem um schema associado, e dependem de documentação auxiliar onde os tipos de dados são definidos para ajudar os clientes da API. Ter uma ferramenta que gere um XML/JSON Schema automaticamente é bem útil, pois manter esse schema em dois lugares diferentes, no código, mesmo q implicitamente, e na documentação, não é mistério nenhum que facilmente a documentação fica desatualizada.

Remote Procedure Calls

Uma parte boa de alguns protocolos de Remote Procedure Call (RPC) é que o schema costuma ser obrigatório, como é o caso de tecnologias meio defasadas como SOAP Web Services, RMI, DCOM, e também com tecnologias mais recentes como Thrift e gRPC (que usa ProtoBuf).

Alguns dos problemas dessa abordagem é que ela tenta criar uma abstração em cima de chamadas remotas parecida com chamadas a funções locais, que são conceitos fundamentalmente diferentes.

Uma função local retorna um valor com sucesso ou retorna um erro, dependendo dos parametros. Uma chamada remota é imprevisível por natureza, pois a rede nem o servidor remoto são confiáveis e podem falhar por razões adversas.

Uma função local pode entrar em um loop infinito ou um deadlock, mas daí a aplicação inteira trava. Uma requisição remota pode não retornar por causa de um timeout, seja por falha na rede ou um servidor não responsivo, e não dá pra saber a priori por que a requisição falhou.

Uma requisição remota pode chegar ao servidor, ser processada, mas a resposta pode falhar em chegar ao cliente. Requisições repetidas podem ser problemáticas.

Enfim, são paradigmas completamente diferentes e, filosoficamente falando, tratar chamadas remotas como chamada à funções é tratar conceitos diferentes de forma parecida.

Apesar de que esses problemas de chamadas remotas são tratados por tecnologias modernas de RPC, com uso de Promises por exemplo. Mas uma "vantagem" conceitual do REST é que ele não tenta mascarar a existencia de uma chamada remota.

Importante deixar claro que não tem certo ou errado e que esses problemas são só conceituais e que na prática é perfeitamente possível lidar com problemas de rede em chamadas RPC.

Fluxo de dados via envio de mensagens

Uma outra maneira de ter fluxo de dados é via envio de mensagens (message-passing). Dessa forma, a comunicação é indireta, através de um intermediário conhecido como Message Queue ou Message Broker. Ferramentas conhecidas são RabbitMQ, ActiveMQ e Apache Kafka. Outra maneira de se trabalhar com message-passing é com algum framework de Actor Model. Frameworks como Akka e Orleans são alguns exemplos.

Algumas vantagens desse modelo de message passing é que há desacoplamento entre o cliente que envia a mensagem e o processo que executa a requisição. Nesse modelo algumas coisas ficam mais fáceis de fazer do que nos outros modelos:

O Message Broker funciona como um buffer entre request e response, assim se acontecer dos processos executando as requisições estarem sobrecarregados, as requisições são enfileiradas pelo broker até que os processos fiquem livres para continuar processando
Os processos que executam as mensagens podem ser escalados independentemente
Uma mensagem pode ser enviada à vários processos diferentes
Se um processo falhar durante o processamento de uma mensagem, a mesma pode ser reenviada a outro processo redundante.

Importante lembrar que as mesmas preocupações com versionamento de schema das mensagens vale nesse modelo, para que processos que executam as mensagens continuem mantendo compatibilidade.

Designing Data Intensive Apps — Um resumo

Breno Ferreira — Wed, 17 Jun 2020 17:49:06 +0000

Estou lendo o livro Designing Data Intensive Apps e resolvi fazer esse resumo aqui para servir de referencia para algumas ideias principais explicadas no livro. Esse resumo não substitui a leitura do livro. Irei abordar os temas do livro de forma mais superficial e quem quiser se aprofundar, leia o livro.

Capítulo 1 — Sistemas de dados

Capítulo 2 — Principais modelos de banco de dados

Capítulo 3 — Como funciona o storage de um banco de dados

Capítulo 4 — Serialização e fluxo de dados

Capítulo 5 — Dados distribuídos - Replicação de dados

Como funciona o storage de um banco de dados

Breno Ferreira — Tue, 16 Jun 2020 12:56:21 +0000

Parte da série sobre o resumo do livro Designing Data Intensive Apps.

No Capítulo 1 foi falado sobre características de sistemas de dados, e no Capítulo 2 sobre modelos de dados. Agora no capítulo 3 será abordado o tema de armazenamento de dados.

Durante muito tempo, me perguntei como exatamente os dados do banco eram armazenados. Quando usava SQL Server reparava que havia os arquivos .mdf e .ldf de cada database, mas tinha a curiosidade de descobrir como funcionava esses arquivos. Enfim, dívidas técnicas da graduação.

No livro, o autor explica algumas técnicas mais comuns utilizadas por DBs conhecidos.

Por que storage dos dados?

Em toda aplicação, os dados são armazenados inicialmente em memória, em alguma estrutura de dados, seja um mapa, lista, fila, árvore, etc.. Essa estruturas de dados formam como se fosse uma "in-memory database" temporária. Temporária por que memória RAM é volátil e não compartilhada com outros processos e/ou servidores. Em algum momento precisamos persistir esses dados de forma mais permanente, ou arriscamos perder todos os dados à qualquer crash da aplicação ou servidor.

Uma estratégia poderia ser serializar a estrutura de dados inteira em algum formato (JSON por exemplo) em um arquivo. Porém, temos que carregar o arquivo inteiro em memoria para podermos trabalhar sobre os dados. Em conjuntos de dados pequenos (de alguns MBs até alguns GBs) pode ser até possível. Mas isso não escala pois memória RAM tem um certo limite e preço alto. Armazenamento em disco é muito mais barato.

Como armazenar os dados?

Como escrever e ler todos os dados de uma vez é muito ineficiente, precisamos de alguma forma ganhar eficiencia nessas duas operações.

Um exemplo bem rudimentar de um banco de um key-value store pode ser criado da seguinte forma:

#!/bin/bash
db_set () {
    echo "$1,$2" >> database
}
db_get () {
    grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

A função db_set insere um dado com uma chave e um valor. A função db_get retorna o valor associado a uma determinada chave.

$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'
$ db_get 42
{"name":"San Francisco","attractions":["Golden Gate Bridge"]}

Repare que a função db_set faz somente um append no arquivo (com o uso do operador >>). Fazer append em algum arquivo funciona de maneira bem eficiente e mais rápida que uma escrita randômica, ou seja, em uma posição aleatória do arquivo.

Porém, a função db_get já tem alguns problemas. Fazer uma pesquisa por uma chave no arquivo requer percorrer potencialmente todo o arquivo (o que é comumente conhecido como full-table scan). Quem já trabalhou com qualquer banco de dados sabe que a solução para full-table scans é um índice.

Hashmap Index

Digamos que voce tenha os seguintes dados em disco:

Podemos construir um índice usando um Hashmap Index, que é uma estrutura de dados que contêm pares chave e valor, ordenados por chave, e o índice funcionaria mapeando as chaves para um offset de bytes no arquivo.

Como dissemos antes, para mantermos performance, escritas são um simples append no arquivo. Porém, se formos adicionando dados no nosso arquivo para sempre, muito rápido ele fica enorme. Além disso, precisamos também de operações de update e delete, além de insert.

A ideia é escrever até que o tamanho do arquivo atinga um certo valor (64KB digamos), e quando esse tamanho for atingido, cria-se um novo segmento de escrita. De tempos em tempos, roda-se um algoritmo que faz compacta esses segmentos com um merge das chaves, geralmente assumindo-se que os últimos valores escritos são os mais atuais, e descartando-se os valores antigos.

Obs: não confunda os dois key-value pairs. Um é armazenado em disco e contém os dados em si. O índice (que armazena os offsets em disco) é armazenado em memória.

Otimização com LSM Tree

Vamos ver agora uma estrutura mais robusta para construção de índices construída em cima dessa ideia de um Hashmap Index.

A ideia é ter duas estruturas de dados separadas. Uma chamada Memtable e outra chamada Sorted String Table (SSTable).

A Memtable é alguma estrutura de dados ordenada, geralmente alguma árvore balanceada como Red-Black Tree ou AVL Tree. Ambas possuem boa eficiencia nas operações de inserção e busca, O(log n). Então podemos manter essa estrutura em memória que irá manter as atualizações mais recentes. Quando essa estrutura chegar a um tamanho limite definido, os dados são escritos em disco, em uma Sorted String Table (SSTable).

A estrutura da SSTable é bem parecida com a descrita acima do Hashmap Index, com a diferença que ao invés dos dados estarem em ordem de escrita, eles são ordenados por chave. Isso aumenta a eficiencia da compactação dos segmentos, pois os dados já estão ordenados. Além disso, o índice em memória não precisa necessariamente conter todas as chaves, pois os dados em disco estão sempre ordenados, caso uma chave não esteja no índice, é possível achar uma chave de valor mais próximo e fazer o scan em disco a partir desse ponto, e assim não ter que fazer um full-table scan em disco, que seria muito custoso.

Essa estrutura de dados dualizada tem o nome de Log-Structured Merge Tree (LSM Tree).

Alguns problemas ainda existem com essa solução:

Crash recovery: caso haja algum crash no servidor ou aplicação, podemos perder os dados da Memtable que ainda não foram persistidos em disco. Para contornar esse problema, ao mesmo tempo que inserimos dados na Memtable, salvamos uma réplica desses dados em disco em ordem de escrita, assim é possível recuperar a Memtable com os dados em disco depois de uma falha.

Outro problema de performance que pode ocorrer é numa busca por uma chave que não existe. Para não ter que fazer uma busca tanto na Memtable quanto na SSTable inteiras, podemos utilizar Bloom Filters, que é uma estrutura de dados probabilística que pode dizer de maneira eficiente que um dado talvez exista no conjunto, mas que diz que um dado com certeza não existe no conjunto.

B-Trees

Índice com LSM Tree é uma técnica até recente. E a técnica mais comum e mais utilizada é diferente: B-Trees.

B-Tree é uma estrutura de dados interessante pois permite que cada nó da arvore tenha mais de um elemento. Isso permite que a arvore tenha uma altura não muito grande, possibilitando armazenar muitos dados de maneira eficiente.

Na B-Tree, os dados em si são armazenados nas folhas. Esses dados podem estar armazenados em memória ou em disco. E os nós, podem servir de índice para esses dados. Como cada nó possui mais de um elemento, é possível carregar blocos de dados de uma vez para serem processados mais eficientemente em memória e depois persistidos em disco novamente.

Armazenando dados com B-Trees também requer um log append-only, similar ao da LSM-Tree, geralmente chamado de Write-Ahead log (WAL), para evitar perda de dados em caso de falhas, com a diferença que os dados são escritos primeiro no WAL, depois persistidos na árvore.

Vantagens e desvantagens de cada abordagem

LSM Trees costumam ter performance de escrita maior, pois os dados podem ser persistidos mais rapidamente na Memtable, e as escritas em disco de SSTables são sequenciais. Apesar de que configurações ruins de merge e compactação de SSTables podem impactar negativamente a performance de escrita.

B-Trees têm a desvantagem de ter que sempre escrever os dados duas vezes (no WAL e na arvore) e tem maior incidencia de escritas randômicas em diferentes segmentos da árvore, que é bem menos eficiente que escrita sequencial, principalmente em discos magnéticos ao invés de SSDs.

Ao contrário de LSM-Trees que podem ter as chaves na Memtable e nas SSTables, B-Tree possuem as chaves existem somente em um lugar, o que é uma enorme vantagem para manutenção de dados consistentes e isolamento de transações.

Esse é um assunto bem extenso e complexo e aqui eu só dei uma resumida bem rápida e de alto nível. O livro aborda outros assuntos como storage para bancos de dados de analytics, column storage, múltiplos índices. Para não tornar esse post muito longo, recomendo a leitura do livro e de literatura adicional sobre o assunto.

originalmente publicado em: https://medium.com/@breno_ferreira/designing-data-intensive-apps-cap%C3%ADtulo-3-eeec8782ab22

Conteúdo sob a licensa CC-BY-NC

Principais modelos de banco de dados

Breno Ferreira — Fri, 05 Jun 2020 16:51:08 +0000

Parte da série sobre o resumo do livro Designing Data Intensive Apps.

No capítulo 1 vimos alguns atributos de sistemas de dados: reliability, scalability e maintainability.

No capítulo 2, o autor explica diferentes tipos de modelos de dados, principalmente os modelos relacional, documento e grafo.

Modelo relacional

Nos anos 60 e 70, os modelos de dados dominantes eram o Network
Model e o Hierarchical Model.

“File:Bachman order processing model.tiff” by Mhkay is licensed under CC BY-SA4.0

“File:Hire.png” by Tsedenjav.Sh is licensed under CC BY-SA 4.0

Mas nos anos 80, o modelo relacional dominou o mercado e esses outros dois modelos se tornaram obsoletos. Isso se deve a dois problemas principais com esses modelos.

Relações many-to-many

No modelo hierárquico, era bem possível representar relações one-to-many, mas não era possível representar relacionamentos many-to-many. Vendo na figura acima, o modelo hierárquico é como uma árvore, ou seja, os nós podem ter muitos filhos, mas cada nó só pode ter um nó ancestral. Nessa estrutura, representar um modelo de "Produtos" e "Pedidos" fica difícil, pois um pedido pode ter vários produtos, mas não é possível o mesmo produto também estar em varios pedidos.

Linguagem de consulta

Os modelos de rede, CODASYL o mais conhecido, relacionamentos many-to-many eram possíveis. Inclusive é um modelo um pouco semelhante ao modelo de grafos que vamos ver mais adiante. Isso já era uma grande vantagem sobre o modelo hierárquico. Porém, o principal problema deste modelo na época era com consultas aos dados.

Por exemplo, se em um modelo de dados como: Escola → Turmas → Alunos, se voce quisesse acessar o dado de um aluno, era necessário percorrer os nós Escola e Turmas para chegar ao dado do aluno.

Além disso, essas consultas eram escritas em linguagens bem imperativas, que, apesar de ter boa performance para a época, eram difíceis de escrever e relativamente frágeis com relação a mudanças no modelo de dados.

Em meados da década de 80, surge os primeiros RDBMS, que além de suportar relacionamentos many-to-many, também tinham uma linguagem de consultas, SQL, bem poderosa, expressiva e declarativa, que permitia ao analista escrever quais
dados a consulta deve retornar, e não como a consulta deve retornar os dados. Com avanços no desenvolvimento das engines de planos de execução de SQL, performance deixou de ser um problema.

Modelo de documentos

No inicio dos anos 2010, depois de quase 30 anos de dominio do modelo relacional, começou a entrar em voga questionar o absolutismo do SQL, por algumas razões, principalmente:

Necessidade de escalabilidade com alto volume de escrita. Ao contrário da década de 80 e 90, agora em 2010 acesso à computadores é mais democratizado e existe a internet, no começo do boom das redes sociais e bilhões de posts por dia. Em um banco de dados relacional, dados consistentes são garantidos, e isso pode after performance de escrita.

Em bancos de dados relacionais, os dados também devem seguir um schema pré-definido. Muitos dos grandes sites dessa época eram escritos em linguagens como Ruby/Rails que pregam uma abordagem mais dinâmica, flexível e expressiva. RDBMSs com seus requerimentos de schema, e também com o problema da Impedância Objeto-Relacional criaram um ambiente que trouxe ideias lá da década de 70 de volta, com uma cara nova. Os modelos NoSQL (Não Relacionais) como Key-Value Stores e Document
Databases começaram a aparecer nesse periodo.

O modelo de documentos por exemplo, é bem parecido com o modelo hierárquico e tem nativamente a mesma restrição com relacionamentos many-to-many, além disso, Document Databases não costumam oferecer suporte a joins entre tabelas. Porém, modelos de documentos favorecem manter dados relacionados próximos, no mesmo documento, evitando assim a necessidade de joins.

Relacional ou Não relacional

A resposta é sempre: depende.

Algumas vantagens do modelo não relacional sobre o relacional:

Flexibilidade de schema: Isso não quer dizer que não há schema. Ele existe. Só que em um modelo de documentos, existe o que é chamado de Schema on Read: o schema não é forçado pelo banco de dados, mas geralmente validado e tratado pela aplicação.

Localidade de dados: um documento geralmente contem todos os dados relacionados a uma entidade, sem a necessidade de joins em outros documentos.

Não há necessidade de ORMs.

Vantagens do banco relacional sobre o não relacional

Suporte nativo a relacionamentos entre entidades, inclusive many-to-many, e joins entre entidades feitos pela própria linguagem de consultas, SQL, removendo a responsabilidade da aplicação de fazer esses joins. Em Document DBs caso seja necessário fazer um join, as vezes há múltiplos roundtrips ao banco, para trazer dados de dois ou mais documentos, enquanto uma única query SQL pode trazer dados de varias tabelas.

Normalização evita dados duplicados e tira a responsabilidade da aplicação de manter consistência dos dados, que é garantida pelo RDBMS.

Exemplo:

Cliente, Pedidos e Produtos — Modelo Relacional

Exemplo Cliente Pedido Produto - Modelo de Documentos

Com esses exemplos dá pra se ter uma ideia das vantagens e desvantagens de cada modelo descritas acima. Repare que o documento de Pedidos já possui quase todos os dados no mesmo documento, com uma certa duplicação dos dados (dos produtos) e uma "chave estrangeira" para o documento de Clientes, que irá forçar a aplicação a fazer o "join" para obter os dados do cliente.

Já o modelo relacional está bem normalizado, sem duplicação de dados, mas que para obter os dados completos do pedido, é necessário fazer join em outras tres tabelas (Produto, Item Produto e cliente). Porém essa consulta é facilmente executada em somente uma requisição ao banco de dados.

Modelo de Grafos

E se seu modelo de dados tem muitas relações many-to-many? Como esse tipo de relacionamento não é suportado em Document Databases, e ter varias tabelas N-N em um modelo relacional (como a tabela ItemPedido acima), torna o modelo e consultas demasiadamente complexas.

O modelo de grafos nesse caso é bom para isso, onde cada entidade pode estar relacionada com qualquer outra entidade.

“File:Property graph model.png” by М.Оюунболор is licensed under CC BY-SA 4.0

Nesse modelo, entidades, também chamadas de nós ou vertices, e os
relacionamentos são as arestas.

Alguns bons exemplos de uso de Graph Databases:

Social Graph: onde vertices podem ser pessoas interconectadas, locais onde empresas estão localizadas, pessoas fazem checkin, posts que tem comentários, likes, shares, etc.

Modelar isso com um modelo de documentos ou relacional pode ser bem mais dificil do que com um modelo de grafos.

Social Graph

Graph Databases tem uma linguagem de consultas, as mais comuns sendo SparQL, Cypher e Datalog.

Um banco de dados de grafos disponivel abertamente para consultas usando a linguagem SparQL é o Wikidata.

Como escolher o modelo?

Uma estratégia é entender primeiro os requerimentos dos relacionamentos entre as entidades. Se houver relacionamentos many-to-many, Document Databases
provavelmente não vai ser a melhor escolha. Já se houver relacionamentos one-to-many onde os dados podem ficar co-localizados na mesma entidade,
desnormalizados e sem requerimentos rigorosos de consistência, um modelo de documentos pode ser adequado. E se voce verificar que as entidade pode ser relacionar com qualquer outra entidade, grafos podem ser uma boa solução.

originalmente publicado em: https://medium.com/@breno_ferreira/designing-data-intensive-apps-resumo-cap-2-4ddf1d5659a1

Conteúdo sob a licensa CC-BY-NC

Características de um sistema de dados

Breno Ferreira — Wed, 03 Jun 2020 11:58:50 +0000

Parte da série sobre o resumo do livro Designing Data Intensive Apps.

Em qualquer sistema que manipule dados (ou seja, todo sistema de informação), há tres pilares sobre os quais as pessoas responsáveis devem pensar:

Reliability
Scalability
Maintainability

Reliability

Propriedade de um sistema de dados de tolerar falhas.

Falhas são invevitáveis, em qualquer sistema (mais sobre esse assunto nos próximos capítulos). O máximo que dá para fazer é tolerá-las. Ou seja, o sistema deveria continuar funcionado mesmo quando houver falhas. Essas falhas podem ser: falhas de hardware, erros de software e erros humanos.

Falhas de hardware

Todo hardware falha. E conforme voce aumenta a escala do seu hardware, a probabilidade de falha aumenta. Em algum momento alguma coisa vai quebrar, e deveria haver hardware redundante para assumir o controle assim que um problema for detectado, idealmente de forma automatizada.

Erros de software

Problemas no software podem causar falhas tão catastróficas quanto um rack no servidor desconectado. Esses podem ser as vezes bugs que podem ser detectados com uma suite de testes melhor e de maior cobertura, mas também podem ser coisas que as vezes são inesperadas, como por exemplo:

Bugs em bibliotecas ou frameworks
Crash do sistema operacional
Algum processo que causa uso muito alto de algum recurso computacional (CPU, memoria, disco ou rede)

E o pior dos casos, quando em um sistema onde há dependencias entre modulos, uma falha em um módulo cascateia e gera falha em outros N módulos dependentes.

O que ajuda a melhorar a tolerancia a falhas de software: testes melhores, diminuir dependencias, restart automático de processos e monitoramento.

Erros humanos

Humanos fazem e operam sistemas. E humanos são conhecidamente não muito confiaveis. E muitos problemas tem sua causa algum erro humano (update sem where em produção, alguém?).

Algumas estratégias para minimizar o impacto de falhas humanas:

Construa o sistema de forma que minimize a chance de errors acontecerem. Boa documentação e interfaces que facilitem o uso e deixem facil fazer a coisa certa e mais dificil fazer a coisa errada.
Desacople os lugares onde as pessoas podem cometer erros dos lugares onde elas causam falhas. Por exemplo, ter um ambiente de testes onde as pessoas podem testar o sistema de forma que erros não causam falhas em produção com maior impacto.
Facilite rollback de mudanças
Boas práticas de liderança para evitar apontar culpados quando falhas humanas acontecem.

Scalability

Primeiramente, precisamos descrever a carga atual do sistema; somente depois podemos discutir questões de crescimento.

Para se ter ideia da escalabilidade de um sistema, é necessario medir a carga e performance atual do sistema. A partir daí, será possível medir e investigar o que acontece quando a carga aumenta. Algumas coisas que é necessario medir:

uso de recursos de hardware (CPU, Memoria, uso de rede, etc.)
tempo de resposta, geralmente medido em percentis (p95, p99, p999). Ou seja, se seu tempo de resposta p95 é 50ms, significa de 95% dos requests responde em 50ms ou menos. Os outros 5% respondem em tempo maior. Aí entram no jogo possíveis SLAs definidos por contrato, que podem definir um p99 ou p999 (99.9%) com alguns limites.
Latencia de comunicação. Não confundir latencia com tempo de resposta. Latencia é o tempo de transporte de mensagens, e não leva em consideração tempo de processamento. Geralmente dá pra assumir que tempo de resposta = latencia + processamento.

É claro que a arquitetura do sistema vai ter um impacto enorme na escalabilidade do sistema. Para definir a arquitetura do sistema, é necessario saber os parametros de carga com os quais o sistema irá trabalhar. Onde vai haver maior demanda? Vai ter mais escrita ou leitura? Qual o tamanho dos dados? Construir um sistema para responder 100K req/s, cada um processando alguns KBs de dados é bem diferente de um sistema que processa 10 de req/s processando 1GB.

Maintainability

Um sistema de facil manutenção torna a vida dos desenvolvedores e dos sys-admins mais facil.

Um sistema com boa manutenibilidade tenta minimizar as dores de manter e operar um sistema, focando em tres areas:

Operabilidade: facilidade de operação do sistema que manter as coisas funcionando bem
Simplicidade: facilidade de compreender como o sistema e suas partes funciona
Capacidade de evolução: quão facil é fazer mudanças no sistema? Requerimentos e casos de uso mudam frequentemente. Complexidade que não é inerente ao problema sendo resolvido mas sim à implementação torna o software mais dificil de mudar e evoluir.

Os próximos capítulos do livro explicam como sistemas de dados diferentes impactam em cada uma dessas tres areas.

originalmente postado em: https://medium.com/@breno_ferreira/designing-data-intensive-apps-um-resumo-1a62de5358f4

Conteúdo sob a licensa CC-BY-NC