Forem: João Antônio

Cell-Based Architecture: o por que estamos sempre tentando mitigar riscos e falhas

João Antônio — Tue, 28 Apr 2026 01:21:56 +0000

Escalar microserviços horizontalmente resolve capacidade. Mas não resolve isolamento, e essa diferença importa mais do que parece.

Cell-Based Architecture é um padrão que ainda é pouco discutido
na comunidade, mas que empresas como AWS, Slack já usam
há anos para garantir que uma falha nunca afete todos os usuários ao mesmo tempo.

A ideia é simples: em vez de escalar instâncias de um mesmo sistema, você replica a stack inteira em unidades independentes chamadas cells, onde cada uma serve um subconjunto da sua base de usuários.

O problema com microserviços tradicionais

Quando escalamos microserviços horizontalmente, normalmente fazemos isso:

O design parece resiliente. Mas na prática, um único ponto de
pressão afeta todos os usuários ao mesmo tempo:

Um bug em deployment? Todo mundo cai.
Um cliente com tráfego absurdo? Degrada a experiência de todos os outros, o famoso noisy neighbor.
Uma falha em cascata? Propaga pelo sistema inteiro.

Escala horizontal resolve capacidade. Não resolve isolamento.

E essa diferença importa muito mais do que parece.

O que é uma Cell

Uma cell é uma unidade autônoma que contém tudo que precisa
para servir um subconjunto de usuários. Aplicação, infraestrutura
e banco de dados juntos, completamente isolados das outras cells.

Cada cell é funcionalmente idêntica às outras. A diferença é que

cada uma serve um pedaço diferente da base de usuários e não sabe
que as outras existem.

As quatro propriedades que importam

### 1. Blast Radius Containment

Se a Cell 2 falha, apenas os usuários entre 1M e 2M são afetados.

Os outros continuam operando normalmente. O raio da explosão é
previsível e limitado antes mesmo do incidente acontecer.

### 2. Noisy Neighbor Isolation

Um cliente corporativo com milhões de requests por dia não consegue
degradar a experiência de outros clientes que estão em cells separadas.
Cada um vive no seu próprio ambiente.

### 3. Canary deployment natural

Você faz deploy na Cell 1, monitora por 30 minutos e só então

propaga para as demais. Sem feature flags complexos. O rollback
é cirúrgico e afeta só quem precisa.

### 4. Compliance e isolamento por região

Precisa garantir que dados de clientes europeus fiquem na Europa?

Cells por região resolvem isso de forma estrutural, não como
um patch em cima de outro patch.

Como o roteamento funciona

O Cell Router é o único componente verdadeiramente global.
Ele resolve para qual cell cada request deve ir:

Request chega
|
Cell Router consulta: qual cell serve esse tenant_id?

|

Encaminha para Cell N

O mapeamento de tenant_id para cell_id fica em um store leve
e altamente disponível. Redis ou DynamoDB funcionam bem aqui ou outro que queira.

## "Mas isso não é só sharding?"

Não exatamente, e essa é a confusão mais comum.

Sharding é uma estratégia de banco de dados. Você distribui
os dados entre múltiplos nós, mas a aplicação continua sendo uma só.

Mas nem tudo nesse modelo representa o melhor dos mundos. Existem partes difíceis nessas decisões arquiteturais.

Por exemplo, caso seja necessário agregar dados de todas as cells, será preciso consultar e processar informações distribuídas em múltiplos bancos. Isso pode aumentar a complexidade das consultas, dos pipelines de dados e da consistência das informações.

Outro ponto importante é a sobrecarga de uma cell específica. Se uma cell começar a receber mais tráfego do que o esperado, migrar usuários ou aumentar sua capacidade sem downtime pode ser bem mais complicado. Como os bancos são separados, a redistribuição de dados exige mais cuidado, planejamento e mecanismos seguros de migração.

Além disso, qualquer mudança estrutural no banco, como alterações de schema, índices ou procedures, precisa ser aplicada em todos os N bancos existentes. Isso exige uma boa estratégia de versionamento, automação e rollout gradual.

Ou seja, apesar de ser uma solução robusta e escalável, ela também traz novos desafios operacionais. Toda decisão arquitetural resolve alguns problemas, mas inevitavelmente adiciona outros.

por quê?

João Antônio — Wed, 04 Feb 2026 10:47:10 +0000

O desenvolvimento de software exige, de certa forma, um esforço "cognitivo" mínimo da máquina. Diante disso, acredito que pontos como entendimento e compreensão profunda produzem soluções cada vez mais robustas para a grande gambiarra que é a combinação de estruturas lógicas que se transformam em instruções com um determinado fim. O comportamento de uma instrução é interpretado com um nível específico de precisão, não de significado.

Essa grande gambiarra nasce da interpretação de sinais elétricos. Enquanto elétrons percorrem circuitos em busca de uma fuga para despejar sua energia em algum ponto final, eles se tornam prisioneiros do próprio circuito. São quase escravos de portas que permitem ou bloqueiam sua passagem, velocistas que correm sem saber para onde, sem linha de chegada, queimando todo o combustível disponível até a dissipação total.

Compreender essas abstrações, assim como as interpretações existentes em cada camada de software e hardware, traz uma enorme sabedoria para a tomada de decisão. Esse entendimento nos conduz à percepção de que tudo depende de contratos fortes e de implementações feitas com o mínimo possível de brechas de sentido e de processo. Quanto mais profundo é o entendimento das camadas, menor é o espaço para ambiguidades e maior é a confiabilidade dos sistemas construídos.

JVM, Java Memory Model e CPU: por que funciona em x86 e quebra em ARM

João Antônio — Mon, 15 Dec 2025 02:17:33 +0000

“Mas nunca deu problema na minha máquina.”

Provavelmente porque sua máquina é x86. Troca pra ARM e alguns bugs de concorrência que estavam “dormindo” aparecem.

A ideia central: x86 costuma ser mais “conservador” na prática, enquanto ARM permite mais reordenações. Se seu código depende de comportamento “bonzinho” do hardware, ele pode sobreviver em x86 e falhar em ARM.

O que o Java Memory Model (JMM) realmente garante

O JMM não fala “threads compartilham memória e pronto”. Ele define:

visibilidade: quando o que uma thread escreveu passa a ser visto por outra
ordem: quais reordenações são permitidas
happens-before: a relação que cria garantias reais entre threads

Sem um happens-before entre duas ações, você não tem garantia de:

ver o valor mais recente
ver as coisas na ordem que você escreveu
ver um objeto “pronto”

Isso é o motivo de muitos bugs “fantasma”.

O erro comum: confiar na ordem do código

Você escreve:

x = 42;
ready = true;

E imagina que outra thread, ao ver ready == true, vai necessariamente ver x == 42.

O JMM permite que, sem sincronização, outra thread observe:

ready == true
x == 0

Porque:

x pode ficar em cache/registrador
as escritas podem ser reordenadas
a outra thread pode ler valores antigos

O clássico pesado: “objeto meio construído”

Esse é o bug mais traiçoeiro.

instance = new MyObject();

Isso parece uma operação, mas por baixo vira algo tipo:

alocar memória
inicializar campos (construtor)
publicar a referência (instance aponta pro objeto)

Sem sincronização, a JVM/CPU podem efetivamente permitir que a publicação (3) aconteça antes da inicialização (2) ser visível para outras threads.

Então uma segunda thread pode ver:

if (instance != null) {
    instance.doSomething();
}

E instance não é null, mas o objeto pode estar com campos ainda em estado “default” (0/null). Em padrões como double-checked locking isso já deu dor real em produção.

Onde volatile entra (e por que resolve)

Se você declara:

private static volatile MyObject instance;

Você ganha duas coisas importantes:

Visibilidade: leitura de volatile vê o valor mais recente (não “preso” em cache local).
Ordem: volatile cria barreiras que impedem certas reordenações ao redor da variável.

Regra que importa:

Uma escrita em um volatile acontece-before de qualquer leitura posterior do mesmo volatile.

Na prática: se a thread B leu instance (volatile) como não-nulo, ela passa a ter garantia de enxergar as escritas que aconteceram antes da thread A publicar essa referência (incluindo os writes do construtor que “prepararam” o objeto).

“Como funciona por baixo dos panos”

Escrita em volatile

Quando a JVM compila uma escrita em volatile, ela precisa garantir que:

todas as escritas anteriores não fiquem “penduradas” e invisíveis

a publicação do valor não “passe na frente” de coisas anteriores

Isso é implementado inserindo memory fences/barriers ao redor do acesso (o tipo exato depende da arquitetura e do JIT).

Leitura de volatile

Quando a JVM compila uma leitura de volatile, ela precisa garantir que:

você não leia um valor velho do cache/registrador
leituras seguintes não sejam movidas “pra antes” dessa leitura

Também usa barreiras e instruções com semântica apropriada.

x86 vs ARM: por que a diferença aparece

x86 (modelo mais forte na prática)

Em x86, muitas reordenações são menos agressivas e a plataforma tende a “ajudar” sem você pedir. Não significa que o código está correto — significa que o bug pode não se manifestar.

Resultado: muita gente escreve código sem happens-before e “passa”.

ARM (modelo mais fraco)

ARM permite mais reordenação e exige sincronização explícita para garantir ordem/visibilidade. Se você não usou volatile/synchronized/locks/atomics, ARM tem mais chance de mostrar o bug.

Resultado: o mesmo programa “ok” em x86 pode falhar em ARM sob carga.

Regra prática (sem filosofia)

Se tem compartilhamento entre threads, escolha uma estratégia:

volatile: bom para flags/estado simples e publicação segura de referência
synchronized/Lock: bom para invariantes e operações compostas
Atomic*: bom para operações atômicas sem lock (CAS), com custos/limites próprios

Se você não tem happens-before, você está apostando na arquitetura e no acaso.

Implementando preço baseado em volumetria com desconto retroativo

João Antônio — Sat, 08 Nov 2025 14:22:56 +0000

Vamos à ideia de trabalhar com tiers por volumetria.
Neste exemplo, defini 3 tiers, onde os valores mínimo e máximo são inclusivos, ou seja, tanto o limite mínimo quanto o limite máximo estão dentro do tier.

Se o max for 0, quer dizer que vai do min até o “infinito”.
Cada tier tem um unitPrice, que é o preço de cada pagamento naquela faixa.

No PlanVersions, a ideia é ter várias versões de um mesmo plano convivendo ao mesmo tempo.

Se rolar uma atualização de preço e você não quiser que os clientes antigos sejam impactados, o EffectiveAt entra justamente pra isso: você usa a data pra decidir qual versão do plano vale pra cada cobrança.

Já o CustomerPricing é o vínculo entre o plano e o cliente — e ali você pode colocar um desconto se o cliente for especial… ou só muito gente boa mesmo kkkkk 😄

aqui abaixo está o uso/exemplo:

keep going until you're satisfied or dead.

equals, hashcode, hashmap

João Antônio — Wed, 22 Oct 2025 01:18:13 +0000

O papel de equals() e hashCode() no Java

Esses dois métodos vêm da classe Object, a base de todas as classes em Java.

Eles determinam como o Java compara objetos e como eles são organizados em coleções baseadas em hash.

equals(Object o)

Define se dois objetos são considerados “iguais”.

Por padrão (em Object), equals() compara referências (endereço na memória).

Classes costumam sobrescrever para comparar conteúdo.

class Cpu {
    String process;
    Pessoa(String process) { this.process = process; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true; 
        if (!(o instanceof Pessoa)) 
        Pessoa p = (Pessoa) o;
        return process.equals(p.process);
    }
}

hashCode()

Retorna um número inteiro usado pelo algoritmo de hashing de coleções como HashMap e HashSet.

Serve para descobrir rapidamente onde o objeto deve ficar (qual bucket).

Objetos “iguais” segundo equals() devem ter o mesmo hashCode(),
o contrário não é obrigatório (mesmo hash não garante igualdade).

@Override
public int hashCode() {
    return Objects.hash(nome);
}

Como o HashMap realmente usa isso

Vamos entender o fluxo interno simplificado:

Você chama map.put(chave, valor).
O Java calcula hash = chave.hashCode().
Esse hash é usado pra determinar qual “bucket” no array interno vai armazenar a entrada.
Dentro do bucket, se houver colisões (outros elementos com mesmo hash), ele compara com equals() para decidir se atualiza o valor ou adiciona outro nó.
Quando você faz map.get(chave), ele repete o processo:
- calcula o mesmo hashCode(),
- vai ao mesmo bucket,
- percorre e compara com equals() até achar a chave correspondente.

O que acontece quando a chave muda

Se você altera qualquer campo da chave depois de adicioná-la ao mapa, o hashCode() calculado na inserção não corresponde mais ao hash atual.

Resultado:

O get() procura no bucket errado, não encontra.
O remove() também falha (não acha a chave antiga).
A entrada continua existindo dentro de um bucket “órfão”.
Isso não é um “vazamento” clássico, mas é um objeto perdido logicamente — ocupa memória, mas não é acessível.

Exemplo problemático

class Product{
    String name;
    int code;

    Product(String name, int code) {
        this.name= name;
        this.code= code;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Product)) return false;
        Produto p = (Product) o;
        return code == p.code;
    }

    @Override
    public int hashCode() {
        return Objects.hash(code);
    }
}

Agora veja o uso:

Map<Produto, Double> precos = new HashMap<>();
Produto p = new Produto("Mouse", 101);
precos.put(p, 79.9);


p.codigo = 999;

// Agora o hash mudou e o mapa não encntra mais a chave
System.out.println(precos.get(p)); //  null
System.out.println(precos.size()); //  1 (ainda existe internamente)

O objeto continua dentro do mapa, mas está “preso” em um bucket diferente e inacessível.

O contrato formal (equals / hashCode contract)

A especificação do Java diz:

Se dois objetos são iguais segundo equals(), eles devem retornar o mesmo valor em hashCode().

Se dois objetos têm hashCode() diferentes, eles não podem ser iguais.

Se dois objetos têm o mesmo hashCode(), eles podem ou não ser iguais (colisão).

Portanto:

equals() → true ⇒ hashCode() igual
hashCode() igual ⇒ equals() pode ser true ou false

feito por João Antônio e caso encontre algum erro, adicione aqui um comentário ou me mande um e-mail.