Um banco de dados é a parte de um aplicativo que armazena dados, garantindo que eles persistam mesmo após a reinicialização do aplicativo, uma falha no servidor ou uma queda de energia. Posteriormente, o aplicativo pode solicitar esses dados em formatos específicos, como um registro identificado por um ID ou uma lista filtrada por usuário.
Para tornar o conceito de “dados” mais concreto, imagine um aplicativo simples de lista de tarefas. Cada tarefa é um registro contendo campos como task_id, user_id, title, completed e created_at, e o aplicativo precisa realizar duas ações básicas: criar uma tarefa e listar as tarefas de um usuário.
Em uma configuração básica com um único servidor, o cliente envia requisições HTTP para um servidor de aplicação, que, por sua vez, lê e grava registros em um banco de dados. O banco de dados assegura a integridade dos dados ao aplicar regras — como “uma linha de tarefa é gravada apenas uma vez por requisição” — mas também introduz latência, visto que as operações de leitura e gravação consomem tempo no disco e na memória. Vamos acompanhar os fluxos dessas duas requisições em um diagrama de blocos.
Em uma solicitação de criação de tarefa, o servidor de aplicação valida os dados de entrada, solicita ao banco de dados a inserção de uma nova linha de tarefa e, em seguida, retorna o novo task_id ao cliente. O cliente só percebe a gravação como persistente após a confirmação do banco de dados; por isso, o banco de dados ocupa uma posição crítica para garantir a integridade dos dados.
Em uma solicitação de listagem de tarefas, o servidor de aplicação solicita ao banco de dados todas as tarefas cujo user_id corresponda ao critério — frequentemente ordenadas por created_at — e, depois, formata a resposta. Quando essa consulta varre mais linhas do que o necessário, o banco de dados realiza mais trabalho e o cliente aguarda mais tempo; assim, o desempenho passa a depender da forma como o banco de dados localiza as linhas correspondentes.
À medida que mais usuários adicionam tarefas, a primeira falha visível costuma ser a lentidão na listagem de tarefas, pois o banco de dados lê um volume excessivo de dados para responder a uma única consulta. Em seguida, um usuário com atividade intensa ou uma lista compartilhada pode gerar esperas por bloqueios (lock waits), onde múltiplas operações de gravação tentam atualizar a mesma linha ou conjunto de linhas, fazendo com que as solicitações entrem em fila em vez de serem concluídas em paralelo. Por fim, se o processo ou a máquina do banco de dados falhar, toda a aplicação para de funcionar, já que todas as solicitações dependem dele. O diagrama a seguir indica esses três pontos críticos em uma mesma linha de referência.