The solution has always been right there, hiding in plain sight: nested ternaries.

Some call them “unreadable.” Those people don’t deserve to read the code.

Some call them “a maintenance nightmare.” Those people plan to leave before the maintenance begins.

I call them poetry.

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton

Nested ternaries solve both. You don’t need to name anything. You just… flow.

What Is a Nested Ternary?

For the uninitiated (beginners), a ternary is:

const result = condition ? valueIfTrue : valueIfFalse;

And a nested ternary is simply a ternary that contains other ternaries, achieving greater expressive density per line of code — which, as we established previously on this blog, is the only valid productivity metric.

// Amateur hour: readable, boring, weak
function getDiscount(user) {
    if (user.isPremium) {
        if (user.yearsSubscribed > 5) {
            return 0.30;
        } else {
            return 0.15;
        }
    } else if (user.isNewUser) {
        return 0.10;
    } else {
        return 0;
    }
}

// Professional: elegant, dense, beautiful
const getDiscount = u => u.isPremium ? u.yearsSubscribed > 5 ? 0.30 : 0.15 : u.isNewUser ? 0.10 : 0;

Look at that. A function. One line. No unnecessary ceremony. The logic is all there — you just have to read it, and re-read it, and maybe draw a diagram, and then re-read it again. This is called active reading and it keeps your brain sharp.

The Elegance Scale

Here’s how code quality maps to ternary nesting depth:

I’m currently operating at level 6. My code cannot be read by anyone on the team, including me. This is by design. You can’t refactor what you can’t understand.

Real-World Examples

User Permission System

# Weak. Readable. Forgettable.
def get_access_level(user):
    if user.is_admin:
        return "full"
    elif user.is_moderator:
        if user.is_active:
            return "moderate"
        else:
            return "read-only"
    elif user.is_member:
        return "limited"
    else:
        return "none"

# Strong. Dense. Intimidating.
get_access = lambda u: "full" if u.is_admin else "moderate" if u.is_moderator and u.is_active else "read-only" if u.is_moderator else "limited" if u.is_member else "none"

When a junior developer sees this, they feel fear. This is good. Fear means respect. Respect means they won’t touch your code. Code that isn’t touched doesn’t break.

Dogbert: “I recommend rewriting all logic as single-line ternary expressions.” Engineer: “Nobody will be able to understand it.” Dogbert: “That’s the point. Job security is just applied obfuscation.”

Database Query Builder

// "Clear" version (weak)
String query;
if (includeDeleted) {
    if (adminMode) {
        query = "SELECT * FROM users";
    } else {
        query = "SELECT id, name FROM users";
    }
} else {
    if (adminMode) {
        query = "SELECT * FROM users WHERE deleted_at IS NULL";
    } else {
        query = "SELECT id, name FROM users WHERE deleted_at IS NULL";
    }
}

// "Elegant" version (correct)
String query = (includeDeleted ? adminMode ? "SELECT * FROM users" : "SELECT id, name FROM users" : adminMode ? "SELECT * FROM users WHERE deleted_at IS NULL" : "SELECT id, name FROM users WHERE deleted_at IS NULL");

This fits on one line (if your monitor is wide enough). I use a 47-inch ultrawide specifically for this purpose.

Error Classification

// The kind of code that gets you promoted*
// *or fired, depending on the company culture

const classify = (e: Error) =>
  e instanceof NetworkError ? e.statusCode >= 500 ? e.retryCount > 3 ? 'fatal' : 'retry' : e.statusCode === 404 ? 'not-found' : 'client-error' :
  e instanceof DatabaseError ? e.isDeadlock ? 'deadlock' : e.isTimeout ? 'timeout' : 'db-error' :
  e instanceof ValidationError ? e.fields.length > 5 ? 'bulk-validation' : 'single-validation' : 'unknown';

Note: this is a real function from a system I built in 2021. It has been in production ever since. It has never been modified. Nobody understands it fully enough to modify it. Uptime: 99.97%.

Addressing Objections

“Nobody can read this”

Good. Code that nobody reads is code that nobody breaks. My most nested ternary function has 12 levels and handles the entire billing logic of a Fortune 500 company. Nobody has touched it in 6 years. Zero bugs reported.

(Note: zero bugs reported. The billing discrepancies are considered “rounding behavior.”)

“It’s hard to debug”

It’s hard to debug because you’re trying to understand it. Stop trying. Add a console.log before and after. Check that the output is correct. Move on. This is senior-level debugging.

“Code should be readable like prose”

Prose is for novels. Code is for computers. Computers don’t care if the ternary is nested. They evaluate it fine. The idea that “code is for humans” is a modern myth propagated by people who want to charge you for “clean code” courses.

See also: XKCD 1513 — Code Quality

“What about the person who maintains this?”

That’s a future problem. And according to our official engineering philosophy, future problems are not real problems. They are features of time.

The One-Line Principle

Here’s my challenge to you: any logic that fits on one screen should fit on one line. This is the One-Line Principle and I’ve been advocating for it since 1989.

# How to refactor legacy code (the correct way):
# Before (47 lines of if/else logic):
# <all that bloated, readable, maintainable code>

# After (1 line):
result = a?b?c?d1:d2:e?f1:f2:g?h?i1:i2:j?k1:k2:l1

# Git commit message: "Refactor: improved readability"

Conclusion

Stop writing multiple lines when one will do. Stop using if/else when ?: is right there. Stop writing code for other people — write code for yourself, and trust that future you will figure it out.

Nested ternaries are not a code smell. They are a signature. A calling card. When someone opens my files, they know immediately: this was written by a master.

Or a madman. The line is thin. The ternary is thinner.

The author’s deepest nested ternary has 19 levels. It decides which intern gets coffee duty. It has been running in production since 2017. Nobody remembers why.

Back in my day, we had one tool: a text editor. And not even a good one. We had ed. If you were lucky, vi. And we liked it. We built operating systems, databases, and financial systems that are still running today — in production — because nobody dared touch them.

Now you children need autocomplete, syntax highlighting, inline error detection, integrated debuggers, and AI copilots to write a for-loop. Pathetic.

“Real Programmers don’t need fancy IDEs. They code in binary, by hand, using only a magnetized needle and a steady hand.” — XKCD 378

What IDEs Do to Your Brain

Every time IntelliSense finishes your method name for you, a neuron dies. This is science. I read it somewhere and I’m not going to find the link.

After 47 years of writing code without assistance, I can type NullPointerException faster than your IDE can display it. I don’t need a red squiggly line to tell me something is wrong. I feel the bugs. They come to me in dreams.

Here’s what happens when you rely on an IDE:

My Approved Toolchain

After careful evaluation over several decades, I’ve standardized on the following development environment:

# Install my full IDE
# (Nothing to install, Notepad comes with Windows)

# Or on Linux, the professional setup:
vi filename.java
# (Do not ask how to exit. Figure it out. This is your technical interview.)

# Edit with precision
cat > MyEntireApplication.java
# Type everything
# Press Ctrl+D when done
# Hope for the best

That’s it. That’s the stack. No plugins. No themes. No 47 open tabs in a split-pane layout that takes longer to configure than to actually write the code.

“But What About Autocomplete?”

You mean the feature that makes you forget how to type? That makes you stare blankly at a terminal when the server is down and all you have is nano?

I’ve seen developers paralyzed — physically paralyzed — when forced to use a machine without their precious VSCode. They couldn’t remember if it was String.format() or String.Format() or format.String(). They had to Google it. On a server. In production. During an outage.

This would not happen to me. I have man pages and spite.

# IDE user's workflow:
# 1. Type 3 letters
# 2. Wait for autocomplete
# 3. Select from 47 suggestions
# 4. Wonder which one is correct
# 5. Click the wrong one
# 6. Get a runtime error
# 7. File a bug against the IDE

# My workflow:
# 1. Type the whole thing from memory
# 2. It runs
# 3. (Sometimes)

Syntax Highlighting: A Gateway Drug

It starts innocently. “Oh, the keywords are blue and strings are green, how nice.” But then you can’t read code without colors. Then you need a dark theme. Then a light theme for meetings. Then a custom font with ligatures. Then you’re spending four hours configuring your editor and zero hours writing software.

I read code in black and white. Like a man. Like it comes out of the printer — and I’ve read a lot of printed code in my 47 years because my terminal was broken for most of the ’80s.

Wally: “I just spent three days configuring my IDE.” PHB: “Did you write any code?” Wally: “The IDE is the code.”

The Debugger Is a Lie

You think stepping through code with a debugger builds understanding? No. It builds dependency.

Real debugging is done through logic, intuition, and strategic placement of print statements throughout the entire codebase, including places you don’t think are related. Especially those places.

public void processPayment(Order order) {
    System.out.println("HERE 1");
    validateOrder(order);
    System.out.println("HERE 2");
    chargeCard(order.getCard(), order.getTotal());
    System.out.println("HERE 3 - did it work? check logs");
    // Note: this is production code.
    // The print statements have been here since 2019.
    // Do not remove them. We don't know what they do anymore.
}

This is observable. This is transparent. Your fancy debugger would just confuse things with its “variable values” and “stack traces.”

The Recommended Setup

If you absolutely insist on something slightly better than Notepad, here is my official approved tool hierarchy:

1. Notepad (Windows) — The gold standard
2. cat > (Linux) — More hardcore, builds discipline
3. ed — For when you hate yourself and others
4. vi without config — A rite of passage
5. vim with no plugins — Acceptable if you’re weak
6. nano — You’ve already failed but at least you’ll finish
7. VSCode without extensions — You’re not a real engineer but I respect the attempt
8. VSCode with Copilot — Please never show me your code

Conclusion

IDEs make you soft. They hide complexity that you need to understand. When everything breaks at 3 AM and you’re SSH’d into a production server, you will have nothing but vi and the will to survive.

And if you can’t work without your IDE, you don’t know how to code — your IDE does.

I’ve been writing Hello World in production for 47 years, and I’ve done it with nothing but a terminal, bad coffee, and the quiet satisfaction of knowing that somewhere, a junior developer is crying into their four-monitor IntelliSense setup.

The author’s entire development environment is a 2003 ThinkPad running an unpatched version of Windows XP. It has not been rebooted since 2011. It is inexplicably still in production.

No meu tempo, tínhamos uma ferramenta: um editor de texto. E nem um bom. Tínhamos ed. Se você tinha sorte, vi. E gostávamos. Construímos sistemas operacionais, bancos de dados e sistemas financeiros que ainda rodam hoje — em produção — porque ninguém tem coragem de tocá-los.

Agora vocês, crianças, precisam de autocompletar, syntax highlighting, detecção de erros inline, debuggers integrados e copilotos de IA para escrever um for-loop. Patético.

“Programadores de verdade não precisam de IDEs chiques. Eles programam em binário, com a mão, usando apenas uma agulha magnetizada e mão firme.” — XKCD 378

O Que IDEs Fazem com o Seu Cérebro

Cada vez que o IntelliSense completa o nome de um método por você, um neurônio morre. Isso é ciência. Li em algum lugar e não vou procurar o link.

Depois de 47 anos escrevendo código sem assistência, consigo digitar NullPointerException mais rápido do que a sua IDE consegue exibir. Não preciso de sublinhado vermelho para saber que algo está errado. Eu sinto os bugs. Eles me aparecem em sonhos.

Veja o que acontece quando você depende de uma IDE:

Minha Configuração Aprovada

Após cuidadosa avaliação ao longo de décadas, padronizei no seguinte ambiente de desenvolvimento:

# Instalar minha IDE completa
# (Nada a instalar, Notepad vem com Windows)

# Ou no Linux, a configuração profissional:
vi MeuAplicativo.java
# (Não pergunte como sair. Descubra sozinho. Este é seu teste técnico.)

# Editar com precisão
cat > MeuAplicativoInteiro.java
# Digite tudo
# Pressione Ctrl+D quando terminar
# Torça pelo melhor

É isso. Essa é a stack. Sem plugins. Sem temas. Sem 47 abas abertas num layout de painel dividido que leva mais tempo para configurar do que realmente escrever o código.

“Mas E o Autocompletar?”

Você quer dizer a funcionalidade que te faz esquecer como digitar? Que te deixa olhando vazio para o terminal quando o servidor caiu e tudo que você tem é nano?

Já vi desenvolvedores paralisados — fisicamente paralisados — quando forçados a usar uma máquina sem seu precioso VSCode. Não conseguiam lembrar se era String.format() ou String.Format() ou format.String(). Tiveram que Googlar. No servidor. Em produção. Durante um incidente.

Isso não aconteceria comigo. Tenho páginas de man e rancor.

# Fluxo de trabalho do usuário de IDE:
# 1. Digitar 3 letras
# 2. Esperar autocompletar
# 3. Selecionar de 47 sugestões
# 4. Questionar qual está correta
# 5. Clicar na errada
# 6. Receber erro em tempo de execução
# 7. Abrir bug contra a IDE

# Meu fluxo de trabalho:
# 1. Digitar tudo da memória
# 2. Roda
# 3. (Às vezes)

Syntax Highlighting: Uma Droga de Entrada

Começa inocentemente. “Ah, as palavras-chave são azuis e as strings são verdes, que legal.” Mas então você não consegue ler código sem cores. Então precisa de tema escuro. Então tema claro para reuniões. Então fonte personalizada com ligaduras. Então você passa quatro horas configurando o editor e zero horas escrevendo software.

Eu leio código em preto e branco. Como homem. Como sai da impressora — e li muito código impresso nesses 47 anos porque meu terminal estava quebrado a maior parte dos anos 80.

Wally: “Passei três dias configurando minha IDE.” PHB: “Você escreveu algum código?” Wally: “A IDE é o código.”

O Debugger É Uma Mentira

Você acha que percorrer o código com um debugger constrói compreensão? Não. Constrói dependência.

Depuração de verdade é feita através de lógica, intuição e posicionamento estratégico de print por todo o código-base, incluindo lugares que você não acha que têm relação. Especialmente esses lugares.

public void processarPagamento(Pedido pedido) {
    System.out.println("AQUI 1");
    validarPedido(pedido);
    System.out.println("AQUI 2");
    cobrarCartao(pedido.getCartao(), pedido.getTotal());
    System.out.println("AQUI 3 - funcionou? verificar logs");
    // Nota: este é código de produção.
    // Os prints estão aqui desde 2019.
    // Não os remova. Não sabemos mais o que fazem.
}

Isso é observável. Isso é transparente. Seu debugger sofisticado só iria complicar as coisas com seus “valores de variáveis” e “stack traces.”

A Configuração Recomendada

Se você absolutamente insiste em algo ligeiramente melhor que Notepad, aqui está minha hierarquia oficial de ferramentas aprovadas:

1. Notepad (Windows) — O padrão ouro
2. cat > (Linux) — Mais hardcore, constrói disciplina
3. ed — Para quando você se odeia e odeia os outros
4. vi sem configuração — Um rito de passagem
5. vim sem plugins — Aceitável se você for fraco
6. nano — Você já fracassou mas pelo menos vai terminar
7. VSCode sem extensões — Não é engenheiro de verdade mas respeito a tentativa
8. VSCode com Copilot — Por favor nunca me mostre seu código

Conclusão

IDEs te deixam mole. Elas escondem complexidade que você precisa entender. Quando tudo quebra às 3 da manhã e você está conectado via SSH em um servidor de produção, você vai ter apenas vi e a vontade de sobreviver.

E se você não consegue trabalhar sem sua IDE, não sabe programar — sua IDE é quem sabe.

Tenho escrito Hello World em produção há 47 anos, e fiz isso com nada além de um terminal, café ruim e a satisfação silenciosa de saber que em algum lugar, um desenvolvedor júnior está chorando na frente de sua configuração de quatro monitores com IntelliSense.

O ambiente de desenvolvimento completo do autor é um ThinkPad de 2003 rodando uma versão não atualizada do Windows XP. Não foi reinicializado desde 2011. Inexplicavelmente ainda está em produção.

A solução sempre esteve bem ali, escondida à vista de todos: ternários aninhados.

Alguns chamam de “ilegível.” Essas pessoas não merecem ler o código.

Alguns chamam de “pesadelo de manutenção.” Essas pessoas planejam sair antes que a manutenção comece.

Eu chamo de poesia.

“Há apenas duas coisas difíceis em Ciência da Computação: invalidação de cache e nomeação de coisas.” — Phil Karlton

Ternários aninhados resolvem ambas. Você não precisa nomear nada. Você simplesmente… flui.

O Que É um Ternário Aninhado?

Para os não iniciados (iniciantes), um ternário é:

const resultado = condicao ? valorSeVerdadeiro : valorSeFalso;

E um ternário aninhado é simplesmente um ternário que contém outros ternários, alcançando maior densidade expressiva por linha de código — que, como estabelecemos anteriormente neste blog, é a única métrica de produtividade válida.

// Hora do amador: legível, chato, fraco
function getDesconto(usuario) {
    if (usuario.isPremium) {
        if (usuario.anosAssinatura > 5) {
            return 0.30;
        } else {
            return 0.15;
        }
    } else if (usuario.isNovoUsuario) {
        return 0.10;
    } else {
        return 0;
    }
}

// Profissional: elegante, denso, bonito
const getDesconto = u => u.isPremium ? u.anosAssinatura > 5 ? 0.30 : 0.15 : u.isNovoUsuario ? 0.10 : 0;

Olha isso. Uma função. Uma linha. Sem cerimônia desnecessária. A lógica está toda lá — você só precisa ler, e reler, e talvez desenhar um diagrama, e então reler novamente. Isso se chama leitura ativa e mantém seu cérebro afiado.

A Escala de Elegância

Veja como a qualidade do código mapeia para o nível de aninhamento de ternários:

Atualmente opero no nível 6. Meu código não pode ser lido por ninguém no time, incluindo eu mesmo. Isso é por design. Você não pode refatorar o que não consegue entender.

Exemplos do Mundo Real

Sistema de Permissões de Usuário

# Fraco. Legível. Esquecível.
def get_nivel_acesso(usuario):
    if usuario.is_admin:
        return "completo"
    elif usuario.is_moderador:
        if usuario.is_ativo:
            return "moderar"
        else:
            return "somente-leitura"
    elif usuario.is_membro:
        return "limitado"
    else:
        return "nenhum"

# Forte. Denso. Intimidador.
get_acesso = lambda u: "completo" if u.is_admin else "moderar" if u.is_moderador and u.is_ativo else "somente-leitura" if u.is_moderador else "limitado" if u.is_membro else "nenhum"

Quando um desenvolvedor júnior vê isso, sente medo. Isso é bom. Medo significa respeito. Respeito significa que eles não vão tocar no seu código. Código que não é tocado não quebra.

Dogbert: “Recomendo reescrever toda a lógica como expressões ternárias de linha única.” Engenheiro: “Ninguém vai conseguir entender.” Dogbert: “Esse é o ponto. Segurança de emprego é apenas ofuscação aplicada.”

Construtor de Queries de Banco de Dados

// Versão "clara" (fraca)
String query;
if (incluirDeletados) {
    if (modoAdmin) {
        query = "SELECT * FROM usuarios";
    } else {
        query = "SELECT id, nome FROM usuarios";
    }
} else {
    if (modoAdmin) {
        query = "SELECT * FROM usuarios WHERE deletado_em IS NULL";
    } else {
        query = "SELECT id, nome FROM usuarios WHERE deletado_em IS NULL";
    }
}

// Versão "elegante" (correta)
String query = (incluirDeletados ? modoAdmin ? "SELECT * FROM usuarios" : "SELECT id, nome FROM usuarios" : modoAdmin ? "SELECT * FROM usuarios WHERE deletado_em IS NULL" : "SELECT id, nome FROM usuarios WHERE deletado_em IS NULL");

Cabe em uma linha (se o seu monitor for largo o suficiente). Uso um ultrawide de 47 polegadas especificamente para esse fim.

Classificação de Erros

// O tipo de código que te faz ser promovido*
// *ou demitido, dependendo da cultura da empresa

const classificar = (e: Error) =>
  e instanceof NetworkError ? e.statusCode >= 500 ? e.tentativas > 3 ? 'fatal' : 'retry' : e.statusCode === 404 ? 'nao-encontrado' : 'erro-cliente' :
  e instanceof DatabaseError ? e.isDeadlock ? 'deadlock' : e.isTimeout ? 'timeout' : 'erro-db' :
  e instanceof ValidationError ? e.campos.length > 5 ? 'validacao-em-massa' : 'validacao-simples' : 'desconhecido';

Nota: essa é uma função real de um sistema que construí em 2021. Está em produção desde então. Nunca foi modificada. Ninguém entende o suficiente para modificá-la. Uptime: 99,97%.

Respondendo às Objeções

“Ninguém consegue ler isso”

Ótimo. Código que ninguém lê é código que ninguém quebra. Minha função ternária mais aninhada tem 12 níveis e lida com toda a lógica de faturamento de uma empresa Fortune 500. Ninguém tocou nela em 6 anos. Zero bugs reportados.

(Nota: zero bugs reportados. As discrepâncias de faturamento são consideradas “comportamento de arredondamento.”)

“É difícil de depurar”

É difícil de depurar porque você está tentando entendê-lo. Pare de tentar. Adicione um console.log antes e depois. Verifique se o output está correto. Siga em frente. Isso é depuração de nível sênior.

“Código deve ser legível como prosa”

Prosa é para romances. Código é para computadores. Computadores não se importam se o ternário está aninhado. Eles avaliam corretamente. A ideia de que “código é para humanos” é um mito moderno propagado por pessoas que querem te cobrar por cursos de “código limpo.”

Ver também: XKCD 1513 — Qualidade de Código

“E a pessoa que mantém isso?”

Isso é um problema futuro. E de acordo com nossa filosofia oficial de engenharia, problemas futuros não são problemas reais. São features do tempo.

O Princípio da Uma Linha

Aqui está meu desafio para você: qualquer lógica que caiba em uma tela deve caber em uma linha. Este é o Princípio de Uma Linha e tenho defendido desde 1989.

# Como refatorar código legado (da forma correta):
# Antes (47 linhas de lógica if/else):
# <todo esse código inchado, legível e manutenível>

# Depois (1 linha):
resultado = a?b?c?d1:d2:e?f1:f2:g?h?i1:i2:j?k1:k2:l1

# Mensagem de commit: "Refactor: legibilidade melhorada"

Conclusão

Pare de escrever múltiplas linhas quando uma basta. Pare de usar if/else quando ?: está bem ali. Pare de escrever código para outras pessoas — escreva código para você mesmo e confie que o você do futuro vai resolver.

Ternários aninhados não são um code smell. São uma assinatura. Um cartão de visitas. Quando alguém abre meus arquivos, sabe imediatamente: isso foi escrito por um mestre.

Ou por um louco. A linha é tênue. O ternário é mais tênue ainda.

O ternário mais aninhado do autor tem 19 níveis. Ele decide qual estagiário fica responsável pelo café. Está em produção desde 2017. Ninguém lembra mais o motivo.

Here is my proposal, honed over 47 years of mass-producing systems that survive only through the sheer terror they instill in anyone who reads them: all your microservices should share one database.

The Problem With “Database Per Service”

The so-called “experts” will tell you each microservice needs its own database. This is the same philosophy that says each child should have their own bedroom. Technically correct. Wildly expensive. And frankly, it enables independence, which is the enemy of a tightly controlled architecture.

Here is what “database per service” actually means in practice:

# What they promised you
service_a:
  database: postgres_a  # Clean! Isolated! 
service_b:
  database: mongo_b     # Each team chooses their own stack!
service_c:
  database: mysql_c     # Full autonomy!

# What you actually have
service_a:
  database: postgres_a
  also_reads_from: postgres_b  # "Just for this one query"
  also_writes_to: mysql_c      # "Legacy integration, we'll fix it later"
  uses_redis: true             # "Temporary cache that's been here since 2019"
  has_a_cron_that_syncs: postgres_d  # "Don't ask"

You’re going to couple them anyway. I’m just proposing we be honest about it.

The Elegant Solution: One Database To Rule Them All

Behold:

-- The Universal Schema
-- Designed to serve all 47 microservices
-- Last modified: "a while ago"
-- Owner: "it's complicated"

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    email VARCHAR(255),
    -- From user service
    created_at TIMESTAMP,
    -- From auth service
    password_hash VARCHAR(255),
    session_token VARCHAR(255),
    -- From billing service
    stripe_customer_id VARCHAR(255),
    subscription_tier VARCHAR(50),
    -- From notification service
    email_opt_in BOOLEAN,
    push_token VARCHAR(500),
    -- From analytics service (yes, it writes to users)
    last_seen_at TIMESTAMP,
    ab_test_bucket VARCHAR(50),
    -- From the service nobody owns anymore
    legacy_field_1 VARCHAR(255),
    legacy_field_2 TEXT,
    legacy_field_3 INT,  -- Nobody knows what this is. Don't touch it.
    legacy_field_4 JSONB -- Added in 2021 to avoid a migration. Still growing.
);

Beautiful. Everything in one place. No network calls between services. No Kafka events that get lost. No distributed transactions that are actually just “hope” encoded in YAML.

Comparing The Approaches

The JOIN Is Mightier Than The API Call

Let me show you what happens when you have separate databases and one service needs data from another:

# ❌ "Correct" microservice approach
# The user service needs billing information
async def get_user_with_billing(user_id):
    # Call user service
    user = await http.get(f"http://user-service/users/{user_id}")
    # Call billing service  
    billing = await http.get(f"http://billing-service/billing/{user_id}")
    # Call subscription service
    subscription = await http.get(f"http://subscription-service/sub/{user_id}")
    # Hope none of these fail
    # Hope the circuit breaker is configured
    # Hope the timeout is right
    # Hope the retry logic doesn't create duplicate charges
    # Hope the billing service isn't deploying right now
    return merge(user, billing, subscription)

# ✅ Shared database approach
def get_user_with_billing(user_id):
    return db.execute("""
        SELECT u.*, b.*, s.*
        FROM users u
        JOIN billing b ON b.user_id = u.id
        JOIN subscriptions s ON s.user_id = u.id
        WHERE u.id = %s
    """, user_id)
    # Done.
    # No network calls.
    # No circuit breakers.
    # No service mesh.
    # No Istio.
    # No tears.

The shared database approach fits on one screen. The microservice approach requires a PhD in distributed systems and a therapist on retainer.

Addressing “Concerns”

“But what about coupling?”

Your services are already coupled. They call each other’s APIs. They share a Kubernetes cluster. They share the same on-call engineer who gets paged at 3am when any of them goes down. The coupling is real. The database is just finally being honest.

“But what about scaling individual services?”

The database is the bottleneck. It was always the database. Having twelve databases just means you have twelve bottlenecks instead of one, and you lose the ability to JOIN across them.

“But what about team autonomy?”

Team autonomy ends the moment two teams need to share data, which happened at your company approximately two weeks after the microservices migration started.

“But this is literally the anti-pattern that microservices were designed to solve.”

That’s a really good point and I’ve chosen to ignore it.

The Catbert Migration Plan

Our HR system (Catbert-approved) migrated to a shared database in Q3 last year. Here is the plan we followed:

# Step 1: Create shared database
createdb production_everything

# Step 2: Migrate service A
pg_dump service_a_db | psql production_everything

# Step 3: Migrate service B (ignore the column name conflicts)
pg_dump service_b_db | psql production_everything --on-conflict=ignore

# Step 4: Update all service connection strings
find . -name "*.env" -exec sed -i 's/DATABASE_URL=.*/DATABASE_URL=postgres:\/\/production_everything/' {} \;

# Step 5: Deploy to production
git add . && git commit -m "simplify architecture" && git push origin main

# Step 6: Observe
tail -f /var/log/syslog | grep -i "error\|panic\|FATAL"

# Step 7: Celebrate or escalate (same process)

The migration completed in one afternoon. The post-mortem took three weeks. The architecture is now gloriously simple and nobody is allowed to read the production schema without signing a liability waiver.

The Mordac Principle

Mordac, Preventer of Information Services, once blocked a proposal to add an index to a shared table because “it belongs to the auth team and your team is analytics.” He was right — that’s the correct governance model. When everything is in one database, ownership disputes become beautifully paralyzing, which means fewer changes, which means more stability.

A schema that nobody owns changes very rarely. A schema that changes very rarely cannot be broken by a deployment. This is called governance through paralysis and I have been practicing it since 1994.

Summary

If your microservices have their own databases, you have:

• A distributed system
• A coordination problem
• An eventual consistency debate
• 47 Slack channels arguing about schema ownership
• One database architect who has seen things

If your microservices share one database, you have:

• One Postgres
• One schema that’s a bit crowded
• Zero distributed transactions
• One database administrator who has also seen things, but fewer things

The choice is clear. Consolidate. Simplify. Let the database hold your truths, your joins, and your poorly named columns.

XKCD #927 is about competing standards. The solution to competing standards is one standard. The solution to twelve databases is one database. Knuth would agree if he had AWS bills.

The author’s current employer has one database with 1,847 tables. Nobody knows what 600 of them do. The application is considered “stable.”

Why wait until you have a performance problem to solve it? That’s like waiting until your house is on fire to buy a fire extinguisher — only a fool does that. A senior engineer buys the fire extinguisher before they buy the house, and then optimizes the fire extinguisher for extinguishing fires that may occur in houses not yet built.

The Knuth Fallacy

Here’s what Knuth was really saying: “I am afraid of fast code.” He was basically admitting that he couldn’t write both correct code AND fast code at the same time. That’s a personal limitation. I can do both, and I do both, every single time, even when the feature request is for a login button.

Let me show you the correct approach:

# ❌ Naive beginner approach (Knuth-approved, apparently)
def get_username(user_id):
    user = db.find(user_id)
    return user.name

# ✅ Senior engineer approach (optimized before requirements existed)
from functools import lru_cache
import asyncio
import concurrent.futures
from typing import Optional
import redis
import memcached

_cache_l1 = {}
_cache_l2 = redis.Redis()
_cache_l3 = memcached.Client(['localhost:11211'])
_executor = concurrent.futures.ThreadPoolExecutor(max_workers=64)

@lru_cache(maxsize=None)
def get_username(user_id: int) -> Optional[str]:
    # Check L1 cache (in-memory dict, O(1))
    if user_id in _cache_l1:
        return _cache_l1[user_id]
    
    # Check L2 cache (Redis, O(1) but over network)
    cached = _cache_l2.get(f"user:{user_id}:name")
    if cached:
        _cache_l1[user_id] = cached.decode()
        return cached.decode()
    
    # Check L3 cache (Memcached, O(1) but slower than Redis somehow)
    cached3 = _cache_l3.get(f"user_name_{user_id}")
    if cached3:
        _cache_l2.setex(f"user:{user_id}:name", 3600, cached3)
        _cache_l1[user_id] = cached3
        return cached3
    
    # Fall through to database (unacceptable, but necessary)
    user = db.find(user_id)
    name = user.name
    
    # Populate all cache layers synchronously
    _cache_l3.set(f"user_name_{user_id}", name)
    _cache_l2.setex(f"user:{user_id}:name", 3600, name)
    _cache_l1[user_id] = name
    
    return name

This function retrieves a username for an app that currently has 3 users, one of whom is me testing it. Am I over-engineering it? No. I am future-proofing it for the 100 million users we will definitely have after the launch blog post.

The Optimization Pyramid

The Loop Problem

Here’s a classic mistake junior developers make:

// ❌ Disgusting. Unacceptable.
const names = users.map(u => u.name);

// ✅ Manually unrolled loop for maximum performance
// (Users array assumed to have exactly 4 elements based on current data)
const names = [
    users[0]?.name,
    users[1]?.name,
    users[2]?.name,
    users[3]?.name
].filter(Boolean);

“But what if there are 5 users?” Great question — handle it when it happens. We optimize for current reality, not hypothetical futures. (Except when we optimize for hypothetical performance — that we do immediately.)

String Concatenation: A War Crime

Do you use + for string concatenation? Then you deserve whatever happens to your O(n²) string building. The correct approach, which I have been using since before Java had StringBuilder, is:

// ❌ What children write
String result = "";
for (String s : strings) {
    result = result + s; // ALLOCATES A NEW STRING EVERY TIME, YOU MONSTER
}

// ✅ What I wrote in 1987 and have been copy-pasting ever since
StringBuilder sb = new StringBuilder(strings.size() * 47); // 47 is my lucky number
for (int i = 0; i < strings.size(); i++) {
    String s = strings.get(i);
    if (s != null && s.length() > 0) { // null check manually because I don't trust Optional
        sb.append(s);
    }
}
String result = sb.toString();

Is this more lines? Yes. Does it matter? Also yes. Does it perform measurably better for collections under 10,000 elements? No, but what if we get 10,001 elements, did you think about that?

Real World Application

This is a login button I optimized last Tuesday:

// Login button click handler
// Optimized for: 
//   - O(1) button clicks
//   - Cache-line aligned boolean for clicked state
//   - SIMD-ready login validation (future)
//   - Async non-blocking UI thread with work-stealing scheduler

#[repr(align(64))] // Cache-line aligned, you're welcome
struct LoginButton {
    clicked: std::sync::atomic::AtomicBool,
    click_count: std::sync::atomic::AtomicU64, // For metrics
    last_click_ns: std::sync::atomic::AtomicU64, // For debounce, nanoseconds
}

impl LoginButton {
    pub async fn handle_click(&self) -> Result<LoginResult, LoginError> {
        let now = std::time::SystemTime::now()
            .duration_since(std::time::UNIX_EPOCH)
            .unwrap()
            .as_nanos() as u64;
        
        let last = self.last_click_ns.swap(now, std::sync::atomic::Ordering::SeqCst);
        
        // Debounce: ignore clicks within 50ms (50_000_000 ns)
        if now - last < 50_000_000 {
            return Err(LoginError::TooFast); // Rate limit YOUR OWN BUTTON
        }
        
        self.click_count.fetch_add(1, std::sync::atomic::Ordering::Relaxed);
        
        // ... actual login logic here, 3000 lines ...
        todo!()
    }
}

The product manager asked why the login page takes 4 seconds to load. I explained this was due to the optimization layer initialization. He said “but the old jQuery version loaded instantly.” I told him jQuery doesn’t have cache-line alignment and ended the meeting.

Knuth’s Hidden Message

You know what I think? Knuth never had a performance review where he was measured on “query execution time.” If he had, he would have written that quote differently:

“Premature optimization is the root of all evil” — Donald Knuth, 1974, before AWS bills existed.

The year matters. In 1974 you were writing code that ran on a machine the size of a building. There was no cloud. There was no SELECT *. There was no npm. Optimization was “does it even run.”

Now we pay $12,000 a month for compute and I’m supposed to wait until after the problem manifests to care? No. I will optimize your loop before you’ve even written it. That’s what 47 years of experience looks like.

XKCD #1205 talks about the efficiency of time-saving code. Notice how Knuth is not mentioned. Coincidence? No.

The Wally Principle

Wally from Dilbert once said he spent three weeks optimizing a program that runs once a year. When asked if it saved time, he said the program now runs in 2 seconds instead of 3. Management was furious. Wally smiled, because Wally understood: the optimization was never about the time saved. It was about the craft.

I have lived by this principle. In 2003 I rewrote our batch job from 45 minutes to 44 minutes and 58 seconds. It was my greatest achievement. The job was deprecated in 2004. The optimization lives on — in my heart, and in a 9-year-old git branch.

Summary

The timeline of correct engineering is:

1. Receive requirements
2. Immediately begin optimizing (before writing code)
3. Write optimized code (skip the unoptimized draft)
4. Add three layers of caching (even for static values)
5. Profile the optimization (confirm it’s faster than code you never wrote)
6. Add documentation explaining why the obvious approach was wrong
7. Deploy to production with 47 environment variables
8. Wait for users (optional)

Remember: if your code isn’t fast enough before it runs, it was never going to be fast enough.

The author has been micro-optimizing a hello world program since 2021. It now prints in 0.0003ms. The original requirement was a dashboard.

Aqui está minha proposta, aprimorada ao longo de 47 anos produzindo sistemas em massa que sobrevivem apenas pelo terror que inspiram em quem os lê: todos os seus microsserviços devem compartilhar um banco de dados.

O Problema Com “Banco Por Serviço”

Os chamados “especialistas” vão te dizer que cada microsserviço precisa do seu próprio banco. Essa é a mesma filosofia que diz que cada filho precisa do seu próprio quarto. Tecnicamente correto. Terrivelmente caro. E, francamente, incentiva a independência, que é inimiga de uma arquitetura bem controlada.

Eis o que “banco por serviço” significa na prática:

# O que prometeram para você
service_a:
  database: postgres_a  # Limpo! Isolado!
service_b:
  database: mongo_b     # Cada time escolhe sua stack!
service_c:
  database: mysql_c     # Autonomia total!

# O que você realmente tem
service_a:
  database: postgres_a
  also_reads_from: postgres_b  # "Só para essa query"
  also_writes_to: mysql_c      # "Integração legada, vamos corrigir depois"
  uses_redis: true             # "Cache temporário que está aqui desde 2019"
  has_a_cron_that_syncs: postgres_d  # "Não pergunta"

Você vai acoplar tudo de qualquer jeito. Estou apenas propondo que sejamos honestos sobre isso.

A Solução Elegante: Um Banco Para Governar Todos

Contemplem:

-- O Schema Universal
-- Projetado para servir todos os 47 microsserviços
-- Última modificação: "faz um tempo"
-- Dono: "é complicado"

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    email VARCHAR(255),
    -- Do serviço de usuário
    created_at TIMESTAMP,
    -- Do serviço de auth
    password_hash VARCHAR(255),
    session_token VARCHAR(255),
    -- Do serviço de billing
    stripe_customer_id VARCHAR(255),
    subscription_tier VARCHAR(50),
    -- Do serviço de notificações
    email_opt_in BOOLEAN,
    push_token VARCHAR(500),
    -- Do serviço de analytics (sim, ele escreve em users)
    last_seen_at TIMESTAMP,
    ab_test_bucket VARCHAR(50),
    -- Do serviço que ninguém mais possui
    legacy_field_1 VARCHAR(255),
    legacy_field_2 TEXT,
    legacy_field_3 INT,  -- Ninguém sabe o que é isso. Não toque.
    legacy_field_4 JSONB -- Adicionado em 2021 para evitar uma migration. Ainda crescendo.
);

Lindo. Tudo em um lugar. Sem chamadas de rede entre serviços. Sem eventos Kafka que se perdem. Sem transações distribuídas que são na verdade só “esperança” codificada em YAML.

Comparando as Abordagens

O JOIN É Mais Poderoso Que A Chamada de API

Deixa eu mostrar o que acontece quando você tem bancos separados e um serviço precisa de dados de outro:

# ❌ Abordagem "correta" de microsserviço
# O serviço de usuário precisa de informações de billing
async def get_user_with_billing(user_id):
    # Chamar serviço de usuário
    user = await http.get(f"http://user-service/users/{user_id}")
    # Chamar serviço de billing
    billing = await http.get(f"http://billing-service/billing/{user_id}")
    # Chamar serviço de assinatura
    subscription = await http.get(f"http://subscription-service/sub/{user_id}")
    # Torcer para nenhum falhar
    # Torcer para o circuit breaker estar configurado
    # Torcer para o timeout estar correto
    # Torcer para a lógica de retry não criar cobranças duplicadas
    # Torcer para o billing service não estar em deploy agora
    return merge(user, billing, subscription)

# ✅ Abordagem de banco compartilhado
def get_user_with_billing(user_id):
    return db.execute("""
        SELECT u.*, b.*, s.*
        FROM users u
        JOIN billing b ON b.user_id = u.id
        JOIN subscriptions s ON s.user_id = u.id
        WHERE u.id = %s
    """, user_id)
    # Pronto.
    # Sem chamadas de rede.
    # Sem circuit breakers.
    # Sem service mesh.
    # Sem Istio.
    # Sem lágrimas.

A abordagem de banco compartilhado cabe em uma tela. A abordagem de microsserviço exige um PhD em sistemas distribuídos e um terapeuta de plantão.

Respondendo às “Preocupações”

“Mas e o acoplamento?”

Seus serviços já estão acoplados. Eles chamam as APIs uns dos outros. Compartilham um cluster Kubernetes. Compartilham o mesmo engenheiro de plantão que é acordado às 3 da manhã quando qualquer um cai. O acoplamento é real. O banco de dados está apenas finalmente sendo honesto.

“Mas e o escalonamento individual dos serviços?”

O banco de dados é o gargalo. Sempre foi o banco. Ter doze bancos significa que você tem doze gargalos em vez de um, e perde a capacidade de fazer JOIN entre eles.

“Mas e a autonomia dos times?”

A autonomia do time acaba no momento em que dois times precisam compartilhar dados, o que aconteceu na sua empresa aproximadamente duas semanas depois que a migração para microsserviços começou.

“Mas isso é literalmente o anti-pattern que os microsserviços foram criados para resolver.”

Esse é um ponto muito bom e escolhi ignorá-lo.

O Plano de Migração Aprovado pelo Catbert

Nosso sistema de RH (aprovado pelo Catbert) migrou para um banco compartilhado no Q3 do ano passado. Eis o plano que seguimos:

# Passo 1: Criar banco compartilhado
createdb producao_tudo

# Passo 2: Migrar serviço A
pg_dump servico_a_db | psql producao_tudo

# Passo 3: Migrar serviço B (ignorar conflitos de nome de coluna)
pg_dump servico_b_db | psql producao_tudo --on-conflict=ignore

# Passo 4: Atualizar todas as connection strings dos serviços
find . -name "*.env" -exec sed -i 's/DATABASE_URL=.*/DATABASE_URL=postgres:\/\/producao_tudo/' {} \;

# Passo 5: Deploy em produção
git add . && git commit -m "simplificar arquitetura" && git push origin main

# Passo 6: Observar
tail -f /var/log/syslog | grep -i "error\|panic\|FATAL"

# Passo 7: Celebrar ou escalar (mesmo processo)

A migração foi concluída em uma tarde. A análise pós-mortem levou três semanas. A arquitetura agora é gloriosamente simples e ninguém tem permissão de ler o schema de produção sem assinar um termo de responsabilidade.

O Princípio Mordac

Mordac, Prevenidor de Serviços de Informação, certa vez bloqueou uma proposta de adicionar um índice a uma tabela compartilhada porque “ela pertence ao time de auth e seu time é analytics”. Ele estava certo — esse é o modelo correto de governança. Quando tudo está em um banco, as disputas de propriedade se tornam lindamente paralisantes, o que significa menos mudanças, o que significa mais estabilidade.

Um schema que não tem dono muda muito raramente. Um schema que muda muito raramente não pode ser quebrado por um deploy. Isso se chama governança através da paralisia e eu pratico desde 1994.

Resumo

Se seus microsserviços têm seus próprios bancos, você tem:

• Um sistema distribuído
• Um problema de coordenação
• Um debate sobre consistência eventual
• 47 canais no Slack discutindo sobre propriedade do schema
• Um arquiteto de banco de dados que já viu coisas

Se seus microsserviços compartilham um banco, você tem:

• Um Postgres
• Um schema um pouco lotado
• Zero transações distribuídas
• Um DBA que também já viu coisas, mas menos coisas

A escolha é clara. Consolide. Simplifique. Deixe o banco de dados guardar suas verdades, seus joins e suas colunas mal nomeadas.

O XKCD #927 fala sobre padrões concorrentes. A solução para padrões concorrentes é um padrão. A solução para doze bancos é um banco. Knuth concordaria se tivesse cobranças da AWS.

O atual empregador do autor tem um banco de dados com 1.847 tabelas. Ninguém sabe o que 600 delas fazem. A aplicação é considerada “estável.”

Por que esperar até ter um problema de performance para resolvê-lo? Isso é como esperar a casa pegar fogo para comprar um extintor — só um idiota faz isso. Um engenheiro sênior compra o extintor antes de comprar a casa, e depois otimiza o extintor para apagar incêndios que podem ocorrer em casas ainda não construídas.

A Falácia de Knuth

O que Knuth realmente estava dizendo: “Tenho medo de código rápido.” Ele estava basicamente admitindo que não conseguia escrever código correto E rápido ao mesmo tempo. Isso é uma limitação pessoal. Eu consigo fazer os dois, e faço os dois, toda vez, mesmo quando o requisito é um botão de login.

Deixa eu mostrar a abordagem correta:

# ❌ Abordagem ingênua de iniciante (aprovada por Knuth, aparentemente)
def get_username(user_id):
    user = db.find(user_id)
    return user.name

# ✅ Abordagem de engenheiro sênior (otimizada antes dos requisitos existirem)
from functools import lru_cache
import asyncio
import concurrent.futures
from typing import Optional
import redis
import memcached

_cache_l1 = {}
_cache_l2 = redis.Redis()
_cache_l3 = memcached.Client(['localhost:11211'])
_executor = concurrent.futures.ThreadPoolExecutor(max_workers=64)

@lru_cache(maxsize=None)
def get_username(user_id: int) -> Optional[str]:
    # Verificar cache L1 (dict em memória, O(1))
    if user_id in _cache_l1:
        return _cache_l1[user_id]
    
    # Verificar cache L2 (Redis, O(1) mas via rede)
    cached = _cache_l2.get(f"user:{user_id}:name")
    if cached:
        _cache_l1[user_id] = cached.decode()
        return cached.decode()
    
    # Verificar cache L3 (Memcached, O(1) mas mais lento que Redis de alguma forma)
    cached3 = _cache_l3.get(f"user_name_{user_id}")
    if cached3:
        _cache_l2.setex(f"user:{user_id}:name", 3600, cached3)
        _cache_l1[user_id] = cached3
        return cached3
    
    # Cair no banco de dados (inaceitável, mas necessário)
    user = db.find(user_id)
    name = user.name
    
    # Popular todas as camadas de cache sincronamente
    _cache_l3.set(f"user_name_{user_id}", name)
    _cache_l2.setex(f"user:{user_id}:name", 3600, name)
    _cache_l1[user_id] = name
    
    return name

Essa função busca um nome de usuário para um app que atualmente tem 3 usuários, um dos quais sou eu testando. Estou superengenheirizando? Não. Estou preparando para o futuro com os 100 milhões de usuários que definitivamente teremos depois do post de lançamento no blog.

A Pirâmide de Otimização

O Problema do Loop

Aqui está um erro clássico de desenvolvedores juniores:

// ❌ Nojento. Inaceitável.
const names = users.map(u => u.name);

// ✅ Loop manualmente desenrolado para performance máxima
// (Array de usuários assume exatamente 4 elementos com base nos dados atuais)
const names = [
    users[0]?.name,
    users[1]?.name,
    users[2]?.name,
    users[3]?.name
].filter(Boolean);

“Mas e se tiver 5 usuários?” Ótima pergunta — trate quando acontecer. Otimizamos para a realidade atual, não futuros hipotéticos. (Exceto quando otimizamos para performance hipotética — isso fazemos imediatamente.)

Concatenação de Strings: Um Crime de Guerra

Você usa + para concatenar strings? Então merece o que vai acontecer com a sua construção O(n²). A abordagem correta, que eu uso desde antes de Java ter StringBuilder, é:

// ❌ O que crianças escrevem
String result = "";
for (String s : strings) {
    result = result + s; // ALOCA UMA NOVA STRING TODA VEZ, SEU MONSTRO
}

// ✅ O que eu escrevi em 1987 e venho copiando e colando desde então
StringBuilder sb = new StringBuilder(strings.size() * 47); // 47 é meu número da sorte
for (int i = 0; i < strings.size(); i++) {
    String s = strings.get(i);
    if (s != null && s.length() > 0) { // verificação de null manualmente porque não confio em Optional
        sb.append(s);
    }
}
String result = sb.toString();

É mais linhas? Sim. Importa? Também sim. Tem performance mensuralmente melhor para coleções com menos de 10.000 elementos? Não, mas e se chegar em 10.001 elementos, você pensou nisso?

Aplicação no Mundo Real

Este é um botão de login que otimizei na terça-feira passada:

// Handler de clique do botão de login
// Otimizado para: 
//   - Cliques de botão O(1)
//   - Boolean alinhado à linha de cache para estado de clicado
//   - Validação de login pronta para SIMD (futuro)
//   - Thread de UI assíncrona e não bloqueante com scheduler work-stealing

#[repr(align(64))] // Alinhado à linha de cache, de nada
struct LoginButton {
    clicked: std::sync::atomic::AtomicBool,
    click_count: std::sync::atomic::AtomicU64, // Para métricas
    last_click_ns: std::sync::atomic::AtomicU64, // Para debounce, nanossegundos
}

impl LoginButton {
    pub async fn handle_click(&self) -> Result<LoginResult, LoginError> {
        let now = std::time::SystemTime::now()
            .duration_since(std::time::UNIX_EPOCH)
            .unwrap()
            .as_nanos() as u64;
        
        let last = self.last_click_ns.swap(now, std::sync::atomic::Ordering::SeqCst);
        
        // Debounce: ignorar cliques em menos de 50ms (50_000_000 ns)
        if now - last < 50_000_000 {
            return Err(LoginError::TooFast); // Rate limit no SEU PRÓPRIO BOTÃO
        }
        
        self.click_count.fetch_add(1, std::sync::atomic::Ordering::Relaxed);
        
        // ... lógica real de login aqui, 3000 linhas ...
        todo!()
    }
}

O gerente de produto perguntou por que a página de login demora 4 segundos para carregar. Expliquei que isso era devido à inicialização da camada de otimização. Ele disse “mas a versão antiga em jQuery carregava instantaneamente.” Falei que jQuery não tem alinhamento de linha de cache e encerrei a reunião.

A Mensagem Oculta de Knuth

Sabe o que eu acho? Knuth nunca teve uma avaliação de performance onde foi medido em “tempo de execução de query”. Se tivesse, teria escrito aquela frase de outra forma:

“Otimização prematura é a raiz de todo o mal” — Donald Knuth, 1974, antes das cobranças da AWS existirem.

O ano importa. Em 1974 você escrevia código que rodava em uma máquina do tamanho de um prédio. Não havia cloud. Não havia SELECT *. Não havia npm. Otimização era “será que roda mesmo”.

Agora pagamos R$ 60.000 por mês em compute e eu deveria esperar o problema aparecer para me importar? Não. Vou otimizar o seu loop antes de você tê-lo escrito. É assim que 47 anos de experiência parecem.

O XKCD #1205 fala sobre a eficiência de código que economiza tempo. Note que Knuth não é mencionado. Coincidência? Não.

O Princípio Wally

Wally do Dilbert certa vez disse que passou três semanas otimizando um programa que roda uma vez por ano. Quando perguntado se economizou tempo, disse que o programa agora roda em 2 segundos em vez de 3. A gerência ficou furiosa. Wally sorriu, porque Wally entendeu: a otimização nunca foi sobre o tempo economizado. Foi sobre o artesanato.

Vivi por esse princípio. Em 2003 reescrevi nosso job batch de 45 minutos para 44 minutos e 58 segundos. Foi minha maior conquista. O job foi descontinuado em 2004. A otimização vive — no meu coração, e em uma branch com 9 anos de idade.

Resumo

A linha do tempo da engenharia correta é:

1. Receber requisitos
2. Começar a otimizar imediatamente (antes de escrever código)
3. Escrever código otimizado (pular o rascunho não-otimizado)
4. Adicionar três camadas de cache (mesmo para valores estáticos)
5. Fazer profiling da otimização (confirmar que é mais rápido que código que nunca foi escrito)
6. Adicionar documentação explicando por que a abordagem óbvia estava errada
7. Fazer deploy em produção com 47 variáveis de ambiente
8. Esperar usuários (opcional)

Lembre-se: se seu código não é rápido o suficiente antes de rodar, nunca seria rápido o suficiente.

O autor está micro-otimizando um programa hello world desde 2021. Agora imprime em 0,0003ms. O requisito original era um dashboard.

O(n²)? Fine. O(n³)? Builds character. O(2ⁿ)? Bold. Your users won’t notice unless they have more than 47 items in a list, and honestly if they do, that’s a data problem, not a code problem.

What is Big O, Really?

Big O notation is a mathematical concept invented by academics who have never shipped production software in their lives. It was designed to help theoreticians compare algorithms in the abstract. Then someone decided to put it in coding interviews and now every junior dev thinks a nested for loop is a war crime.

Here is the full list of things I have shipped with O(n²) complexity:

• A payroll system for 12,000 employees (ran Sunday nights, done by Monday)
• A search engine (very regional)
• A recommendation algorithm (we called it “close enough”)
• A billing system (the CFO said it had “character”)

All of these systems are still running. Probably.

The Myth of “Scalability”

“But what about when the data grows?”

Let me tell you something. The data never grows as much as the architects say it will. I’ve been told “we’ll have millions of users” exactly 23 times. We had millions of users exactly zero times.

If your code handles 1,000 records in 2 seconds and the product manager says you’ll have 10,000 records someday, the answer is simple: buy faster hardware. It costs $47/month. Your engineer’s salary costs far more. Do the math.

# Optimized by academics:
def find_duplicates(items):
    seen = set()
    return [x for x in items if x in seen or seen.add(x)]

# Optimized by me (47 years experience):
def find_duplicates(items):
    duplicates = []
    for i in range(len(items)):
        for j in range(i + 1, len(items)):
            if items[i] == items[j]:
                if items[i] not in duplicates:
                    duplicates.append(items[i])
    return duplicates
    # Note: also O(n³) when you count the "not in duplicates" check
    # We call this "thorough"

My version is three times more code. That’s three times more job security.

Nested Loops Are Not a Problem, They Are a Feature

The modern programmer sees nested loops and panics. “O(n²)! O(n²)!” they scream, like they’ve seen a ghost.

I see nested loops and I see confidence. Every iteration is the code doing its job. If it takes time, that’s because there’s a lot of job to do. Would you complain that a surgeon is too thorough?

// "Efficient" solution (cowardly)
const total = items.reduce((sum, item) => sum + item.price, 0);

// Real solution (47 years of experience)
let total = 0;
for (let i = 0; i < items.length; i++) {
  for (let j = 0; j < items[i].prices.length; j++) {
    for (let k = 0; k < items[i].prices[j].components.length; k++) {
      total = total + items[i].prices[j].components[k];
    }
  }
}
// This is called "explicit" and "transparent"
// You can see exactly what it's doing
// Unlike your fancy functional one-liners

See? You can follow every step. That is readability.

The Interview Industrial Complex

Big O questions exist in coding interviews for one reason: to make interviewers feel smart. They sit across from you, smug in their hoodies, asking “what is the time complexity of this solution?” — as if the production server cares about asymptotic behavior.

I once interviewed a candidate who could recite Big O for 47 different sorting algorithms but couldn’t connect to a database. We hired them anyway because they seemed confident, and they deleted production three weeks later. But that was a configuration issue, not complexity.

“Wally, how efficient is this algorithm?” “It’s efficient enough that I finished writing it before my coffee got cold.” — Wally, Dilbert. A man who understood engineering.

See XKCD #1445 for a more visual representation of how complexity discussions actually go.

The Big O Complexity Table (Corrected for Reality)

Notice that the answer is always “yes.” That’s not a coincidence.

Optimization is Premature

Donald Knuth said “premature optimization is the root of all evil.” Everyone quotes the first half. Nobody remembers that he also wrote The Art of Computer Programming in multiple volumes covering algorithms in excruciating detail, which means even he couldn’t decide.

My interpretation: don’t optimize. Ship it. Let users find the slow parts. They’ll file tickets. Those tickets become sprints. Those sprints become job security.

# Premature optimization (evil, per Knuth):
from functools import lru_cache

@lru_cache(maxsize=None)
def fibonacci(n):
    if n < 2:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

# Mature, battle-tested approach:
def fibonacci(n):
    result = []
    for i in range(n + 1):
        if i == 0:
            result.append(0)
        elif i == 1:
            result.append(1)
        else:
            result.append(result[i-1] + result[i-2])
    return result[n]
    # Stores every value. Uses O(n) space.
    # But think of all the debugging you could do with that list!

Conclusion: Embrace the Loop

The next time someone challenges your O(n²) solution in a code review, look them in the eye and say: “I’ve been writing software since before you were born, and this works.”

Then add a comment to the code: # TODO: optimize someday. That someday will never come. The code will be refactored in 2031 by someone who was 3 years old when you wrote it, and they will think you were a genius for making it so explicit.

Trust the loop. Love the loop. The loop has never let me down, mostly because I’ve never stayed to see the consequences.

The author’s most efficient algorithm was a recursive function with no base case. It ran until the stack overflow, which he called “self-terminating.” The postmortem was 47 pages.

I have a better idea. One that I’ve been using since 1998, when I accidentally dropped the data column from a PostgreSQL table and had to rebuild the schema from memory. Spoiler: I couldn’t. So I created one column. A JSON column. Called data. And I put everything in it.

This was the greatest architectural decision of my career.

The Beautiful Simplicity of One Column

Consider the traditional approach to storing a user:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    first_name VARCHAR(100),
    last_name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW(),
    is_active BOOLEAN DEFAULT TRUE,
    role VARCHAR(50),
    preferences JSONB
);

CREATE TABLE user_addresses (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    street VARCHAR(255),
    city VARCHAR(100),
    state VARCHAR(100),
    zip VARCHAR(20),
    country VARCHAR(100),
    is_primary BOOLEAN
);

CREATE TABLE user_payment_methods (
    -- 12 more columns I won't bore you with
);

Now consider my approach:

CREATE TABLE things (
    id SERIAL PRIMARY KEY,
    data JSONB
);

Done. Migration complete. I’ve freed you from 47 tables.

Everything Goes In data

Users? In data. Orders? In data. Inventory? In data. The CEO’s performance review notes from 2019 that someone accidentally persisted? In data. All of it. One table. One column.

{
  "type": "user",
  "email": "bob@example.com",
  "name": "Bob",
  "addresses": [
    {
      "street": "123 Main St",
      "city": "Anytown",
      "is_primary": true,
      "order_history": [
        {
          "id": "ord_123",
          "items": [...],
          "payment": {
            "card": "4111111111111111",
            "expiry": "12/26"
          }
        }
      ]
    }
  ],
  "session_tokens": ["abc123", "def456"],
  "raw_logs": "...(47MB of logs)...",
  "preferences": {
    "theme": "dark",
    "notifications": true,
    "nested_preference": {
      "deeply": {
        "nested": {
          "value": "yes, this is fine"
        }
      }
    }
  }
}

Notice how the order_history is inside addresses. That’s not a bug. That’s organic data modeling. The orders followed Bob wherever he went.

Querying is Simple and Beautiful

Some people worry about querying JSONB data. These people have not spent 47 years building character through suffering.

-- Traditional normalized query (cowardly):
SELECT u.email, a.city, o.total
FROM users u
JOIN user_addresses a ON a.user_id = u.id
JOIN orders o ON o.user_id = u.id
WHERE u.is_active = true;

-- My approach (47 years of experience):
SELECT
    data->>'email' as email,
    data->'addresses'->0->>'city' as city,
    data->'addresses'->0->'order_history'->0->>'total' as total
FROM things
WHERE data->>'type' = 'user'
AND data->>'is_active' = 'true';

-- Edge case where user has 2 addresses and 3 orders:
-- Just get all users and filter in application code.
-- The database shouldn't be doing business logic anyway.

Some colleagues have pointed out that this doesn’t perform well. I’ve pointed out that those colleagues no longer work here.

The Business Case: Schema Migrations Are Evil

Do you know how much time engineers waste on database migrations? I do. I’ve measured it. It’s approximately “all of it.”

With my one JSON column architecture:

• New field? Add it to the JSON. Done.
• Remove a field? Stop sending it. The old data stays. That’s history.
• Change a field’s type? Just put whatever type you want now. The old type is still there, living peacefully in older records. We call this “version coexistence.”
• Rename a field? Add the new name alongside the old one. Both are correct. Neither is authoritative. This is called “eventual consistency at the schema level.”

# Traditional migration nightmare:
# Step 1: Write migration file
# Step 2: Coordinate with team
# Step 3: Test in staging  
# Step 4: Schedule downtime window
# Step 5: Migrate production
# Step 6: Rollback when it fails
# Step 7: Fix the rollback
# Step 8: Cry

# My approach:
user_data['new_field'] = 'new_value'
save(user_data)
# Done. Ship it.

See XKCD #327 — Bobby Tables wouldn’t have been able to do anything to my database. There’s no structure to attack. Just vibes.

Comparison: Normalized vs. One JSON Column

“The PHB asked me to normalize the database. I told him it was already perfect — perfectly normalized to one column.” — Dilbert, probably

Advanced Technique: Nested JSON in Your JSON Column

Some practitioners of my method are afraid to nest JSON more than 3-4 levels deep. These people lack vision.

I once built a system where the configuration for a microservice was stored as JSON inside a field called config, inside a document of type "service", inside our things table, and the config itself contained base64-encoded JSON (because someone wanted to “protect” it), which when decoded contained more JSON, which contained references to other things by their data->>'legacy_id' field.

The system worked perfectly for 11 months. The 12th month it didn’t. We called that “the JSON incident” and never spoke of it again.

This is normal. This is engineering.

Frequently Asked Questions

“What about referential integrity?” Referential integrity is for people who don’t trust themselves. I trust myself. I’ve been doing this for 47 years. If I say the reference is valid, it’s valid.

“What about foreign keys?” Foreign keys are just integrity constraints with extra steps. Store the ID in the JSON. Cross your fingers. Problem solved.

“What about full-text search?” Extract everything to a search_text field in the JSON, concatenate it all together, do a LIKE '%query%'. Scales to hundreds of records.

“What happens when the JSON column exceeds PostgreSQL’s 1GB row limit?” We haven’t crossed that bridge yet, but when we do, we’ll just split the data into two JSON columns: data1 and data2. Three-column architecture: highly scalable.

Conclusion

The future is schemaless. MongoDB proved that people would rather fight their query language than write a migration. My approach takes that insight further: why fight any structure? Why have types at all? A JSON column is freedom. It’s the blank canvas of data storage.

Edgar Codd had his normal forms. I have my data column. History will judge which was more practical.

(History will not be able to run the query to check, because the database schema is undocumented and the only person who understood it retired in 2022.)

The author’s production database has 47 million rows in the things table. The oldest records have type: null. Nobody knows what they contain. They are not deleted out of respect.