DEV Community: Nadachi

O que são essas letrinhas: BASE

Nadachi — Mon, 03 Aug 2026 22:07:23 +0000

Continuando com a saga de siglas, encontrei de maneira simplista a versão oposta do ACID, o BASE. Dizemos que é a versão oposta por conta de que os pontos focados por esse paradigma são totalmente diferentes do que o ACID tem como proposta, sem enrolação, vamos para as explicações.

O que é
- B
- S
- E
Na prática
Conclusão

O que é

Dizemos que ele é a versão oposta do ACID por conta de que o modelo do BASE é focar na disponibilidade dos dados, ou seja, em detrimento da consistência dos dados, não iremos falhar a transação feita pelo usuário e sim iremos disponibilizar algum dado inconsistente por algum tempo. Agora explicando o que cada letra significa.

B

Basically available ou basicamente disponível, tem como premissa que cada request vai receber uma response, podendo ela não estar 100% atualizada. Então decidimos retornar respostas temporárias ou dados antigos com o objetivo de sempre retornar uma informação.

S

Soft state ou Estado flexível, tem como premissa que os dados podem mudar com o tempo, mesmo sem nenhuma nova operação do usuário. Concordo, meio viagem isso, mas a ideia em si é que você em algum momento pode estar vendo uma informação X e logo depois pode estar vendo informação Y, isso acontece porque os bancos estão sincronizando as informações, um bom exemplo disso é esse que tem no artigo do site da AWS, ele diz

Por exemplo, se os usuários editarem uma publicação nas redes sociais, a alteração poderá não ser visível para outros usuários imediatamente. No entanto, mais tarde, a postagem é atualizada sozinha (refletindo a alteração mais antiga), mesmo que nenhum usuário a tenha acionado.

A ideia geral é que uma transação foi feita e, com o tempo, os nós dos bancos vão ser sincronizados com essa informação atualizada.

E

Eventual Consistency ou Consistência Eventual, isso diz que em algum ponto os dados vão estar consistentes, no geral, a propagação da atualização da informação vai ser feita de forma async, destacando aqui, não existindo garantia de quando, mas ela vai.

Na prática

Vamos ver agora na prática como funcionariam essas siglas. Primeiro, vamos utilizar o banco Cassandra via Docker por ser mais prático, então vamos criar os seguintes cenarios:

docker run -d \
  --name cass1 \
  --hostname cass1 \
  --network cassandra-net \
  -e CASSANDRA_CLUSTER_NAME=Lab \
  -e CASSANDRA_SEEDS=cass1 \
  -e MAX_HEAP_SIZE=512M \
  -e HEAP_NEWSIZE=100M \
  cassandra:5.0

docker run -d \
  --name cass2 \
  --hostname cass2 \
  --network cassandra-net \
  -e CASSANDRA_CLUSTER_NAME=Lab \
  -e CASSANDRA_SEEDS=cass1 \
  -e MAX_HEAP_SIZE=512M \
  -e HEAP_NEWSIZE=100M \
  cassandra:5.0

docker run -d \
  --name cass3 \
  --hostname cass3 \
  --network cassandra-net \
  -e CASSANDRA_CLUSTER_NAME=Lab \
  -e CASSANDRA_SEEDS=cass1 \
  -e MAX_HEAP_SIZE=512M \
  -e HEAP_NEWSIZE=100M \
  cassandra:5.0

Vamos entrar agora no cass1:

docker exec -it cass1 cqlsh

Após isso, vamos criar um Keyspace dentro:

CREATE KEYSPACE teste
WITH replication = {
    'class':'SimpleStrategy',
    'replication_factor':3
};

Entre nele:

USE teste;

Crie uma tabela:

CREATE TABLE contas ( id UUID PRIMARY KEY, nome TEXT, saldo INT );

Insira um dado nela:

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Fulano', 1000);

Vamos buscar o valor da tabela:

SELECT * FROM contas;

O resultado esperado:

 id                                   | nome   | saldo
--------------------------------------+--------+-------
 babb3e16-e2ae-4a87-8435-c0dd09897042 | Fulano |  1000

Estando tudo ok, vamos simular uma queda:

docker stop cass3

Usando o comando abaixo, vamos ter algo informando o que está UN (em pé) e DN (desligado):

docker exec -it cass1 nodetool status

Após o comando rodar, o cass3 vai estar mostrando com DN (desligado), vamos inserir agora outro dado:

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Ciclano', 1000);

Vamos ver se a informação foi salva com sucesso:

SELECT * FROM contas;

O resultado é:

 id                                   | nome    | saldo
--------------------------------------+---------+-------
 babb3e16-e2ae-4a87-8435-c0dd09897042 |  Fulano |  1000
 9461234c-9458-44aa-be0d-3310a14a0944 | Ciclano |  1000

Com isso, validamos o princípio de Basically Available, que mostra que o sistema continua aceitando operações mesmo com parte do cluster fora. Para simular o cenário do Eventual Consistency vamos desligar novamente o cass3:

docker stop cass3

Acessar o cass1:

docker exec -it cass1 cqlsh

Inserir diversos dados:

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Alice', 1000);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Bruno', 1500);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Carlos', 2000);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Daniel', 2500);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Eduardo', 3000);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Fernanda', 3500);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Gabriela', 4000);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Henrique', 4500);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'Isabela', 5000);

INSERT INTO contas (id, nome, saldo)
VALUES (uuid(), 'João', 5500);

Veja quantos dados foram inseridos:

SELECT COUNT(*) FROM contas;

O retorno esperado é:

 count
-------
    12

Liguem novamente o cass3:

docker start cass3

Acessem o cqlsh do cass3:

docker exec -it cass3 cqlsh

Acesse o keyspace teste:

USE teste;

Veja a quantidade de dados tem no cass3:

SELECT COUNT(*) FROM contas;

O retorno esperado é:

 count
-------
    12

Esse retorno valida a ideia do Eventual Consistency, pois vimos que mesmo com o cass3 desligado, após a gente ligar de novo, vemos que os dados ficaram consistentes.

Obs: Para validar o Soft State poderíamos simular usando TTL, fazendo com que registros com tempo de expiração desapareçam e mudem com a sincronização.

Conclusão

Com esse estudo conseguimos ver como funciona BASE e por que ele é considerado o "inverso" do ACID, e principalmente, quais pontos principalmente ele quer resolver, que é com relação à disponibilidade do serviço ao invés de consistência de dados.

O que são essas letrinhas: ACID

Nadachi — Fri, 17 Jul 2026 17:33:10 +0000

Nesses últimos tempos, estou tentando entender muito mais como funciona, quando usar ou o porquê de certas tecnologias, principalmente que envolve System Design, e uma delas que estou estudando está sendo Banco de Dados, e nos meus estudos esses dias, me deparei com diversos termos, principalmente sendo somente iniciais de palavras, com isso decidi ir mais a fundo sobre eles compilando o que aprendi.

O que é
- A
- C
- I
- D
Na prática
Conclusão

O que é

ACID simplesmente é um acrônimo (conjunto de letras) para as palavras em inglês Atomicity, Consistency, Isolation e Durability, que em português significam Atomicidade, Consistência, Isolamento e Durabilidade. Para contexto histórico, foi inventado em 1983 por Andreas Reuter e Theo Härder. A ideia por trás do ACID é de serem propriedades que vão servir de paradigmas para as transações realizadas nos bancos de dados, paradigmas esses que prezam bastante a consistência de informações. Esse paradigma é adotado por todos os bancos relacionais (SQL) como Postgres e MySQL, só que hoje em dia, já é adotado por bancos não relacionais como MongoDB ou FoundationDB, tem vários outros só que ainda parcialmente. A importância desse paradigma surgiu quando começamos a ter contextos que precisavam de grande consistência de dados, como um exemplo mais famoso, o contexto financeiro, onde um erro pode ser muito grave. Agora vamos para a explicação de cada letra.

A

Essa letra é para a palavra em inglês Atomicity ou Atomicidade em português, que usamos para expressar que algo é atômico, ou seja, algo que não é feito em partes, é feito completo. Essa parte do paradigma foi criada com o intuito de que as transações realizadas para os bancos de dados sejam executadas completamente, sem nenhum tipo de parcialidade, sendo a famosa frase que todo mundo fala quando vai explicar "é tudo executado ou nada é executado", não vai existir um meio termo ou parte executada porque ela existe para manter a consistência dos dados, no final, todo o paradigma é com o intuito de manter a consistência dos dados.

C

Agora vamos para Consistency ou Consistência, que tem como objetivo manter a consistência das regras, ou da integridade dos casos. Por exemplo, temos uma loja, para que o cliente faça uma compra, precisamos que ele seja um usuário para vincular a compra ao usuário dele. Dependendo da forma que você for modelar, vai precisar usar Chave Estrangeira (FK), isso por si só já é uma forma de regras para os dados e ao mesmo tempo de manter a integridade dos dados.

I

Esse é o Isolation ou Isolação, que tem como ideia que uma transação não pode interromper outra transação. Trazendo para um exemplo prático, se eu quiser ver as informações de um usuário na plataforma ao mesmo tempo que outra pessoa está querendo ver as informações ou editar simultaneamente, nenhuma das nossas transações vai atrapalhar a outra.

D

Por último, Durability ou Durabilidade, é o mais simples de entender que é, todas as transações têm que ser persistidas, independente de qualquer tipo de falha como queda de internet, luz e etc

Na prática

Vamos subir um ambiente PostgreSQL, usando como ambiente de exemplo o financeiro e de maneira muito simples, então vamos focar somente em como acontece na prática.

Crie uma tabela

 CREATE TABLE contas ( id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, nome TEXT, saldo NUMERIC );

Insira as seguintes informações

INSERT INTO contas (nome, saldo) VALUES ('Fulano', 100), ('Ciclano', 50);

Vamos fazer uma transferência (adição de saldo)

BEGIN; 
UPDATE contas 
SET saldo = saldo - 50 
WHERE id = 1; 

UPDATE contas 
SET saldo = saldo + 30 
WHERE id = 2; 

COMMIT;

Obs: Foi feita aqui uma transação, se olharem bem, teve o BEGIN da transação e, por último o COMMIT, com isso finalizando a transação.
Após o COMMIT, Fulano vai ter saldo de 50 e Ciclano vai ter de 80, mas se algum momento ocorresse um erro por usar algum campo errado no update ou set, a transação iria usar o ROLLBACK para desfazer tudo que deu certo, com isso, mantivemos a atomicidade dos dados.

Seguindo com o mesmo exemplo, vamos criar uma regra de negócio que é: Saldo nunca pode ficar abaixo de zero.

Vamos usar a constraint para isso:

ALTER TABLE contas ADD CONSTRAINT saldo_positivo CHECK (saldo >= 0);

Vamos tentar adicionar um valor abaixo de zero:

BEGIN;

UPDATE contas
SET saldo = saldo - 60
WHERE id = 1;

COMMIT;

O PostgreSQL vai responder:

BEGIN
ERROR:  new row for relation "contas" violates check constraint "saldo_positivo"
DETAIL:  Failing row contains (1, Fulano, -10).
ROLLBACK

Por conta de que ele precisa manter a consistência de dados, com isso, respeitar a regra criada. Abrindo dois terminais, digite em um o comando sem COMMIT:

BEGIN;

UPDATE contas
SET saldo = saldo + 500
WHERE id = 1;

No outro terminal, digite o comando:

SELECT * FROM contas WHERE id=1;

Vai retornar:

 id |  nome  | saldo
----+--------+-------
  1 | Fulano |    50
(1 row)

Isso acontece por conta de que no primeiro terminal a transação não foi commitada, então a informação ainda não foi realmente atualizada, com isso, no primeiro terminal rode o comando:

COMMIT;

Rodando novamente no segundo terminal o comando:

SELECT * FROM contas WHERE id=1;

Vai ser retornado:

 id |  nome  | saldo
----+--------+-------
  1 | Fulano |   550
(1 row)

Com isso, vemos que foi mantido o isolamento entre as transações, com nenhuma transbordando para a outra.
O último é bem difícil, quase impossível de demonstrar, mas imagina que você fez uma transação de adição de saldo para a conta 1, só que antes de o banco realizar o Commit, caiu a luz de onde está o seu banco de dados. O PostregSQL tem uma tecnologia de log chamada WAL (Write Ahead Log) que vai salvar em disco o log dessa transação e, após o banco retornar, vai refazer a alteração.

Conclusão

Eu achei bem interessante aprender sobre ACID e também BASE (futuramente vou trazer sobre), porque mostra um dos vários motivos de como se escolher quando deve ser usado um banco relacional e um não relacional, e isso era uma coisa que sempre tive dúvida em projetos, e com conhecimento sobre esses paradigmas, se entende que dependendo do contexto que for, é bem importante usar um tipo de banco do que o outro.

DEV Community: Nadachi

O que são essas letrinhas: BASE

Table of contents

O que é

B

S

E

Na prática

Conclusão

O que são essas letrinhas: ACID

Table of contents

O que é

A

C

I

D

Na prática

Conclusão