DEV Community: Matheus de Camargo Marques

PON-BEAM: um paradigma orientado a notificações dentro da máquina virtual do Erlang

Matheus de Camargo Marques — Wed, 05 Aug 2026 18:10:11 +0000

PON-BEAM: um paradigma orientado a notificações dentro da máquina virtual do Erlang

1. A pergunta que move este projeto

Todo programador Elixir ou Erlang já ouviu o mantra: "a BEAM é uma máquina virtual altamente concorrente, com milhões de processos leves, trocas de contexto em microsegundos e escalabilidade quase linear". E isso é verdade — para o modelo de programação.

Mas quando você abre o código em C da ERTS (Erlang Run-Time System) e olha como a máquina funciona por dentro, encontra uma surpresa: a BEAM é um motor híbrido. Ela tem notificações para algumas coisas, mas ainda puxa (polling) e faz scans lineares em vários dos subsistemas mais críticos:

Subsistema	Mecanismo no BEAM stock (OTP 30)	Custo
`receive` seletivo	Scan linear da mailbox (cada cláusula contra cada mensagem)	$O(N \times M)$
Timers	Timer wheel com ticks periódicos de polling	O(1) por tick, mas a CPU nunca dorme
Scheduler SMP	Run-queue pollada / busy-spin quando ocioso	5–30% de um core desperdiçado
Coletor de lixo	Varredura de heap por raízes	$O(\text{heap total})$
ETS	Lookups com lock + busca	contention na chave quente

Esse é exatamente o tipo de problema que o Paradigma Orientado a Notificações (PON / NOP), criado pelo professor Dr. Jean Marcelo Simão (UTFPR, 2005–2009), se propõe a eliminar: redundância temporal (reavaliações desnecessárias) e redundância estrutural (código de busca repetido).

O PON-BEAM (repositório: matheuscamarques/pon_beam) é uma re-arquitetura completa da BEAM onde todo subsistema interno vira uma entidade reativa PON: mensagens empurram notificações, em vez de a máquina puxar estados.

A tese central: Nenhum trabalho anterior aplicou o PON como princípio fundacional do motor da VM. A literatura NOP implementa o paradigma em cima de plataformas existentes (C++, Java, FPGA, Erlang). O PON-BEAM propõe o PON como o próprio design da máquina.

Este artigo explica, um a um, cada componente PON que foi integrado à VMBEAM — o que ele substitui, como foi implementado em C na ERTS, e quais ganhos empíricos o harness de benchmarks mediu.

2. O paradigma PON em 5 minutos

Antes de falar de cada componente, os conceitos básicos do PON:

Entidade: qualquer elemento da aplicação (um processo Erlang, um scheduler, um objeto de heap) tratado como reativo e desacoplado. Uma entidade contém dois tipos de elementos:
- FAD (Facts / dados): o estado da entidade.
- FBE (Fundamental Behavior Element / procedimentos): o comportamento.
Premise: uma condição mínima sobre os fatos de uma entidade. Ela só é avaliada quando notificada — e não periodicamente. Ex.: "uma mensagem {gen_call, From, Req} chegou na mailbox".
Condition: uma conjunção de Premises. Quando todas as Premises de uma Condition estão satisfeitas, a Condition notifica uma Instigação.
Instigation: dispara a execução de um método (FBE) quando sua condição causal/temporal se torna verdadeira. No PON-BEAM, os timers são Instigações temporais.
Notificação: o único mecanismo de colaboração entre entidades. É ponto-a-ponto (quem muda sabe quem deve ser avisado), reativa (só dispara quando o fato muda) e sem polling.

A inversão de controle é radical: no modelo imperativo clássico a entidade pergunta "o estado mudou?". No PON, o estado muda e avisa quem o observa.

flowchart LR
    subgraph Stock ["BEAM Stock (OTP 30) — Polling e Scan"]
        direction TB
        A["receive: scan linear da mailbox O(N·M)"]
        B["timer wheel: ticks periódicos"]
        C["scheduler: busy-spin 5–30% CPU"]
    end
    subgraph Pon ["PON-BEAM — Grafos Reativos de Push"]
        direction TB
        Cond["Condition (chegada de estado/mensagem)"]
        Prem["Premise (slot de pattern match)"]
        Instig["Instigation (salto O(1) de execução)"]
        Cond -->|"empurra evento"| Prem
        Prem -->|"satisfaz"| Instig
    end
    Stock ==>|"re-arquitetado como"| Pon

3. A fundação: um overlay compilável sobre o OTP

Antes de qualquer subsistema, a Fase 0 estabeleceu como o PON-BEAM existe junto do OTP stock. As regras de ouro do projeto:

Nunca tocar no baseline. O OTP original vive imutável na branch otp-30.0-rc0-stock.
Toda modificação C fica dentro de #ifdef PON_BEAM. O código original permanece intacto — o PON-BEAM é um overlay compilável, não um fork divergente.
Um artefato por fase: um #ifdef, um benchmark diferencial e uma telemetria.

Isso garante 100% de compatibilidade retroativa: o formato .beam, a ABI de NIFs e o protocolo de distribuição não mudam. Um mesmo pool de código compila beam.smp (stock) ou beam.ponbeam.smp (PON) dependendo do flag -DPON_BEAM.

A telemetria da prova: `pon_stats.h`

Para medir que o comportamento reativo realmente aconteceu (e não só intuir), cada componente PON escreve contadores thread-local por scheduler:

/* pon_stats.h — um contador por scheduler (thread-local) */
typedef struct {
    /* === PON-Receive === */
    Uint64 premises_registered;      /* Premises registradas */
    Uint64 premise_notifications;    /* Premises notificadas na chegada de msg */
    Uint64 mailbox_scans_avoided;    /* Scans lineares evitados pelo advance O(1) */
    Uint64 messages_classified;      /* Mensagens classificadas por tipo */
    /* === PON-Timer === */
    Uint64 timerfd_created;
    Uint64 timerfd_expirations;
    /* === PON-Scheduler === */
    Uint64 condition_wakeups;
    Uint64 scheduler_idle_blocks;
    /* === PON-ETS === */
    Uint64 ets_watchers_registered;
    Uint64 ets_watcher_hits;
    /* === PON-GC === */
    Uint64 gc_notifications_sent;
    Uint64 gc_scans_avoided;
    Uint64 gc_incremental_steps;
    /* === Temporais === */
    Uint64 pon_overhead_us;
} PonStats;

Os contadores são expostos ao Erlang via erlang:system_info(pon_stats) e cada benchmark os lê para validar o mecanismo (ex.: nº de mailbox_scans_avoided confirma que o receive pulou o scan).

4. Componente #1 — PON-Receive (Fase 1): Premises na mailbox

O problema: `O(N × M)`

O receive seletivo do Erlang é a fundação da concorrência da BEAM, mas o intérprete do OTP faz o scan: quando você tem

receive
    {gen_call, From, Req} -> handle(From, Req);
    {cast, Msg}           -> handle_cast(Msg);
    stop                  -> shutdown()
end

e a mailbox tem N mensagens não relacionadas, o intérprete tenta, em ordem de chegada, cada uma das M cláusulas contra cada uma das N mensagens até achar um match. Um gen_server com 10.000 mensagens pendentes custa 4.500µs; com 100.000, 82.000µs.

A solução: Premises

Uma Premise PON-BEAM é um slot de pattern match compilado registrado pelo processo no momento do receive. Quando uma mensagem compatível chega na mailbox, ela notifica a Premise — em vez de a mailbox ser escaneada mais tarde.

/* pon_premise.h — Entidade Premise adaptada à mailbox da BEAM */
typedef struct ErtsPremise_ {
    Eterm                pattern;        /* Padrão compilado (como termo) */
    int                  (*match_fn)(Eterm); /* Função de match otimizada */
    int                  has_match;      /* 1 se há mensagem casada disponível */
    Eterm                matched_term;   /* Termo da mensagem casada */
    struct erl_mesg      *matched_msg;   /* Referência para a mensagem */
    Uint                 clause_index;   /* Índice da cláusula (ordem) */
    struct ErtsPremise_  *next_premise;  /* Lista ligada de premises */
} ErtsPremise;

O fluxo tem três momentos:

1. Classificação rápida por tag de tipo. Na chegada da mensagem, erts_pon_notify_premises() extrai o 1º elemento da tupla e usa os 8 bits baixos dele para indexar um dos 256 buckets (pon_type_tag), mantendo um contador de mensagens por bucket. Isso isola, em $O(1)$, o subconjunto de mensagens potencialmente relevantes:

#define PON_NUM_TYPE_BUCKETS (1 << 8)
#define pon_type_tag(term) ((Uint)(term) & (PON_NUM_TYPE_BUCKETS - 1))

2. Notificação da Premise. Cada Premise possui um match_fn especializado (gerado pelo compilador) ou o fallback erts_pon_default_match(). Se casa, a Premise guarda o termo, a mensagem e uma sequência de chegada global monotônica (erts_pon_next_msg_seq()), necessária para preservar a semântica do receive seletivo multi-cláusula (a mensagem mais antiga casa primeiro).

3. Advance O(1) — o pulo do gato. O hook central é no enqueue (lado do envio): cada mensagem recebe um pon_in_link, que é o endereço do ponteiro da fila que aponta para ela (prev->next ou &sig_qs.first):

/* erl_proc_sig_queue.c — grava o link de entrada fora da janela do receive */
#ifdef PON_BEAM
    if (rp->pon_premises && num_msgs && !is_to_buffer) {
        if (ERTS_SIG_IS_MSG(first))
            first->pon_in_link = this;
    }
#endif

Depois, no loop_rec_end do interpretador, erts_pon_advance_to_matched() reposiciona o save pointer da fila principal diretamente para o endereço da mensagem casada — sem caminhar a lista, sem pattern matching por mensagem:

/* pon_premise.c — fast-path do selective receive */
if (m && m->pon_in_link && *m->pon_in_link == m
    && qs->save != m->pon_in_link) {
    qs->save = m->pon_in_link;              /* salto O(1) */
    PON_STATS_INC(mailbox_scans_avoided);
    return 1;
}

A validação *pon_in_link == matched_msg é um gate de segurança: se a mensagem já foi consumida por outra via ou o gambar foi alcançado pelo scan normal, a Premise é marcada obsoleta e o scan linear segue como fallback (correto, apenas mais lento). Os casos de caminhos não instrumentados (buffers multi-mensagem, flush de sig_inq, concatenação de cadeias) também registram pon_in_link — todos os caminhos de entrada da mensagem estão cobertos.

Resultado medido

N (mensagens na mailbox)	Stock	PON-BEAM	Speedup
100	45.2 µs	8.5 µs	5.3×
1.000	320 µs	9.2 µs	34.8×
10.000	4.500 µs	10 µs	445×
100.000	82.000 µs	12 µs	6.665×

A latência do receive PON no plota ~15µs em todo o range de 100 a 50.000 mensagens — o gap cresce monotonicamente com N, confirmando uma inversão assintótica ($O(N \times M) \to O(1)$), e não um ganho de constante.

5. Componente #2 — PON-Timer (Fase 2): Instigações com `timerfd`

O problema: o timer wheel nunca dorme

A BEAM usa um timer wheel com resolução de 1ms. Mesmo com zero timers ativos, o sistema de timers executa ticks periódicos para varrer o wheel em busca de expirações — consumindo ~3% de um core sem fazer nada. Com 50.000 timers registrados, o custo de checagem chega a 50.000.000 checagens/seg com ~15% de CPU.

A solução: Instigações temporais com o kernel

Uma Instigation PON é um evento futuro que, quando satisfeito, notifica um processo-alvo. No PON-BEAM a expiração de um timer fica a cargo do kernel Linux: cada timer vira um timerfd monitorado por epoll. A VM só acorda no único próximo evento vencido — e nunca varre o wheel.

/* pon_timer.c — cria o timerfd e registra na epoll */
int pon_timer_instigation_create(ErtsTimerInstigation *inst) {
    ...
    tfd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);
    spec.it_value.tv_sec  = (long)(timeout_ms / 1000);
    spec.it_value.tv_nsec = (long)((timeout_ms % 1000) * 1000000ULL);
    timerfd_settime(tfd, 0, &spec, NULL);
    ev.events   = EPOLLIN;
    ev.data.ptr = (void *)inst;
    epoll_ctl(pon_timer_epoll_fd, EPOLL_CTL_ADD, tfd, &ev);
    inst->timer_fd = tfd;
}

A entidade ErtsTimerInstigation guarda o fd, o alvo (target) e a mensagem a entregar na expiração:

/* pon_instigation.h */
typedef struct {
    ErtsInstigation   base;       /* type, fired, target, message, next */
    int               timer_fd;   /* timerfd (−1 se inativo) */
    uint64_t          expiration_ms;
} ErtsTimerInstigation;

pon_timer_process_expirations() faz um epoll_wait(fd, events, 64, 0) não-bloqueante e dispara cada Instigação vencida — drenando as expirações em lote, sem custo proporcional ao número total de timers.

Resultado medido

Cenário	Stock	PON-BEAM
CPU ociosa com 0 timers	~3% de 1 core	0.0%
10 timers (1s)	~3.1%	0.001%
50.000 timers (1s)	~15% CPU / 50M checagens/s	~0.1% / 5 checagens/s

O custo total de timers registrados cai de "varredura do wheel" para "quase nada" — $10.000.000\times$ em checagens por segundo.

6. Componente #3 — PON-Spawn (Fase 3): notificação no agendamento

O problema

Cada spawn percorre o caminho de criação de processo (alocar PCB, inscrever no process table, inserir na run queue) e a latência média de criação fica em ~15µs — com uma cauda longa de jitter sob rajadas.

A solução

A Fase 3 integrou um hook de notificação no caminho de agendamento: quando um processo é criado (ou tornando-se pronto), erts_schedule_process() dispara erts_pon_schedule_notify(p) — que incrementa os contadores de Condition e avisa o scheduler-alvo que há trabalho disponível:

/* erl_process.c — hook no agendamento */
void
erts_schedule_process(Process *p, erts_aint32_t state, ErtsProcLocks locks)
{
    schedule_process(p, state, locks);
#ifdef PON_BEAM
    erts_pon_schedule_notify(p);
#endif
}

Resultado medido

Latência média de spawn: ~15µs → ~8µs (~2×).
Tempestade de 50.000 spawns: pico de 86µs (stock) → 69µs (−19,7%), com a cauda longa de jitter eliminada — uma distribuição mais estreita e previsível.

7. Componente #4 — PON-Scheduler (Fase 4): Conditions com `eventfd` + `epoll`

O problema: o busy-spin ocioso

No OTP stock, quando não há processos prontos, o scheduler cai num loop de checagem da run queue que queima 5–30% de um core por scheduler. Num servidor de 32 cores, isso pode ser 1,6–9,6 cores inteiros girando à toa. A reativação de um processo ocioso mede 10–100µs.

A solução: a Condition

Uma Condition PON é a conjunção de Premises: quando as premissas de um processo estão satisfeitas, ela notifica o scheduler. No PON-BEAM, a Condition substitui a run queue passiva por uma máquina de notificação kernel-space:

eventfd: contador kernel onde o scheduler dorme (epoll_wait) até um byte ser escrito.
epoll: multiplexa os eventfds de wakeup + os timerfd das Instigações da Fase 2.
ready_list lock-free: uma pilha de processos prontos inserida por CAS (compare-and-swap), tolerante a produtores concorrentes.

/* pon_condition.c — notificação do scheduler */
void pon_condition_notify(ErtsCondition *cond, void *process) {
    void **node = (void **)process;
    void *old_head;
    do {
        old_head = atomic_load_explicit((atomic_uintptr_t *)&cond->ready_list,
                                        memory_order_acquire);
        *node = old_head;
    } while (!atomic_compare_exchange_weak_explicit(
        (atomic_uintptr_t *)&cond->ready_list, (uintptr_t *)&old_head,
        (uintptr_t)process, memory_order_release, memory_order_acquire));
    cond->notify_count++;
    if (!cond->satisfied) {                    /* só acorda se estiver dormindo */
        cond->satisfied = 1;
        uint64_t one = 1;
        write(cond->wake_fd, &one, sizeof(one));
    }
}

E o consumidor — o scheduler — bloqueia até o kernel entregar a notificação:

void *pon_condition_wait(ErtsCondition *cond) {
    ...
    int nfds = epoll_wait(cond->epoll_fd, events, PON_CONDITION_BATCH_SIZE, -1);
    if (nfds > 0) { cond->satisfied = 1; continue; }  /* volta a drenar a lista */
}

O padrão check-then-drain é crucial para não perder wakes: o consumidor tenta primeiro drenar a ready_list via CAS; se o CAS falha (produtor chegou no meio), tenta de novo; se a lista está vazia mas o eventfd tem dados, lê o eventfd; só então bloqueia em epoll_wait. Notificações perdidas são impossíveis no design.

Uma nota de transparência sobre esta fase (que vale para todo o projeto): o histórico de commits documenta inclusive o bug que o caminho seguro precisou corrigir — uma versão anterior usava o primeiro byte do struct Process como node da ready_list, mas o 1º campo é o PID (common.id); sobrescrevê-lo corrompia Eterms e produzia size_object: bad tag. A implementação final não embute nada no Process: o avanço real para uma ready_list com node próprio + consumo real pelo scheduler é o que a fase seguinte formaliza (ver docs/STORYTELLING.md).

Resultado medido

Cenário	Stock	PON-BEAM
CPU ociosa (0 processos ativos)	5–30% de 1 core	0.0%
Latência de reativação	10–100 µs	~1 µs (~50×)
100 processos I/O-bound	10–40%	10–20%

8. Componente #5 — PON-ETS (Fase 5): side-table de watchers

O problema

A tabela ETS é o "Redis dentro da BEAM", mas consultas repetidas à mesma chave quente pagam a cada acesso: lock da tabela + caminhada da estrutura (hash/tree). Sob contenção, o throughput cai drasticamente.

A solução: watchers desacoplados

Em vez de pesquisar a chave repetidamente, processos observam chaves: um registro lateral (completamente desacoplado da tabela) mapeia (table_id, key_hash) → processos interessados. Em 1024 buckets (PON_ETS_WATCHER_BUCKETS):

/* pon_ets.h — registro lateral de watchers */
#define PON_ETS_WATCHER_BUCKETS 1024

typedef struct PonEtsWatcher_ {
    uint64_t           table_id;
    uint64_t           key_hash;
    uint64_t           process_id;
    int                active;
    struct PonEtsWatcher_ *next;
} PonEtsWatcher;

/* pon_ets.c — notifica todos os watchers de uma chave */
int pon_ets_watcher_notify(PonEtsWatcherRegistry *reg,
                           uint64_t table_id, uint64_t key_hash) {
    unsigned bucket = pon_ets_watcher_bucket(table_id, key_hash);
    ...
    while (w) {
        if (w->active && w->table_id == table_id && w->key_hash == key_hash) {
            /* envia {ets_change, TableId, Key} para p->mailbox (via Fases 1+4) */
            notified++;
            PON_STATS_INC(ets_watcher_hits);
        }
        w = w->next;
    }
    return notified;
}

O registro inclui limpeza por processo (pon_ets_watcher_remove_process) — quando um watcher morre, suas observações são removidas em varredura pelos buckets.

Resultado medido

1.000 lookups repetidos na mesma chave: 200µs → 0,8µs (250×) — a observação vira notificação, "busca" vira "push".
Chave quente sob contenção: stock 1,70M ops/s (1,25M leituras + 0,45M escritas) → PON-BEAM 11,96M ops/s (9,97M leituras + 1,99M escritas) ≈ 7× de throughput combinado, porque a notificação bypassa a busca e a trava.

9. Componente #6 — PON-Compiler (Fase 6): o `receive` vira Premise

O problema

Para as Premises do PON-Receive terem match_fn especializados, alguém precisa gerá-los. Um receive normal desce pelo pipeline (Core Erlang → SSA → BEAM opcodes) como loop_rec/wait tradicional.

A solução: parse transform para Premises

A Fase 6 entrega o pon_compiler, um parse_transform que reescreve blocos receive do AST para o trio reativo registrar-premises → receber → despachar:

%% harness/benchmarks/lib/pon_compiler.erl
%% Uso: -compile({parse_transform, pon_compiler}).

%% Cada cláusula vira uma Premise
build_premise_list(L, Clauses) ->
    Patterns = lists:map(
        fun({clause, _CL, [Pat], _Gs, _Bd}) ->
            {tuple, 0, [pat_to_term(0, Pat), {atom, 0, true}, {integer, 0, 0}]}
        end, Clauses),
    list_to_ast(L, Patterns).

build_pon_receive(L, Clauses, After) ->
    MsgVar = {var, 0, 'PonMsg'},
    Register = {call, 0, {remote, 0, {atom, 0, pon_runtime},
                          {atom, 0, register_premises}}, [PremiseList]},
    Recv = {match, 0, MsgVar,
            {call, 0, {remote, 0, {atom, 0, pon_runtime},
                       {atom, 0, receive_msg}}, []}},
    Dispatch = build_dispatch(L, Clauses, MsgVar),
    Unreg = {call, 0, {remote, 0, {atom, 0, pon_runtime},
                       {atom, 0, unregister_premises}}, []},
    [Register, Recv, Dispatch, Unreg].

O runtime (pon_runtime.erl) fornece register_premises/1, receive_msg/0, receive_msg_timeout/1 e unregister_premises/0 — e toda a infra da Fase 1 (buckets, pon_in_link, advance O(1)) se conecta abaixo. O plano de engenharia registra também o objetivo de lidar com Guards e After na forma SSA nativa (Premises nativas no bytecode) como evolução da fase.

Resultado

O benchmark fase6_compile.erl e o fase6_stress_compiler.erl medem a compilação de módulos com receives transformados via pon_compiler, validando que o circuito compilação-notificação entrega receive nativo O(1) ao invés do scan linear.

10. Componente #7 — PON-GC (Fase 7): coleta tri-color por notificação (Dijkstra)

O problema

O GC major do OTP é stop-the-world: ele varre o heap inteiro a partir das raízes procurando vivos. Num heap de 100MB onde só 10% dos objetos estão vivos, o GC ainda examina os 100MB — o custo é proporcional ao heap total, não aos vivos.

A solução: marcação por notificação

O PON-GC adapta o algoritmo tri-color de Dijkstra (1978) para o mundo PON: em vez de "varreia pelo mark", a descoberta de vivos é um grafo de notificações:

WHITE → ninguém notificou (lixo suspeito).
GRAY → foi notificado (vivo), está na fila de processamento.
BLACK → notificou suas referências (vivo, verificado).

/* pon_gc.c — cores */
static void enqueue_gray(PonGcState *gc, PonGcNode *node) {
    if (!node || node->color != PON_GC_WHITE) return;
    node->color = PON_GC_GRAY;
    gc->live_nodes++;
    /* append na fila gray (WHITE -> GRAY) */
}

O mark é uma rajada de notificações: as raízes notificam suas referências (GRAY), cada GRAY notifica as suas (criando novos GRAY) e fica BLACK, até a fila esvaziar.

uint64_t pon_gc_mark(PonGcState *gc) {
    for (i = 0; i < gc->num_roots; i++)
        enqueue_gray(gc, gc->roots[i]);     /* Fase 1: raízes notificam */
    while (gc->gray_head) {                 /* Fase 2: propaga até esvaziar */
        PonGcNode *node = dequeue_gray(gc);
        propagate(gc, node);                /* notifica refs; vira BLACK */
    }
    gc->cycles++;
}

O sweep sim é barato: só itera a lista global e libera quem permaneceu WHITE — objetos que nunca foram "examinados" individualmente:

if (node->color == PON_GC_WHITE) {
    gc->dead_nodes++;                       /* morto: nunca notificado */
    gc->bytes_freed += node->data_size;
    pon_gc_node_free(gc, node);
} else {
    node->color = PON_GC_WHITE;             /* vivo: volta a WHITE p/ próximo ciclo */
}

E o GC também é incremental: pon_gc_step(gc, max_notifications) processa até N notificações por fatia de tempo, devolvendo 1 quando o mark termina — o que dá origem a finas de pausa (P99 mais curto).

A integração com a ERTS é via o estado por processo (p->pon_gc) + BIFs de diagnóstico:

pon_gc:register_objects(Sizes) -> [Id]   %% cria os nós do grafo
pon_gc:add_root(Id) -> true | false       %% registra raiz
pon_gc:add_ref(From, To) -> true | false  %% aresta from -> to
pon_gc:collect() -> map                    %% colhe lixo WHITE
pon_gc:dump() -> map                       %% telemetria

E o hook real no ciclo de GC do processo (erts_pon_gc_process_gc em erl_gc.c:816) roda o mark por notificação e acumula nos contadores gc_notifications_sent, gc_scans_avoided e gc_incremental_steps.

Resultado medido

Cenário	Stock	PON-BEAM
Heap 100MB, 10% vivos	varre 100MB inteiros	varre só ~10MB vivos (10×)
Heap 90% lixo, latência média de GC	~645 ms (P99 ~940ms)	~475 ms (−26,3%), fila P99 menor

O custo assintótico inverte de $O(\text{heap total})$ para $\mathcal{O}(V_{\text{live}} + E_{\text{live}})$ — só o que está vivo é percorrido. O custo colateral previsível é a memória extra do grafo de nós (by_id, refs, listas) — documentado como "overhead predizível" de ~3GB para 1M de processos no cenário de type_queues.

11. Visão consolidada: onde cada entidade PON vive

ERTS C Execution Engine                        Erlang Compiler Pass
┌──────────────────────────────────────┐   ┌──────────────────────────┐
│ PON-Receive   → ErtsPremise        │   │ PON-Compiler            │
│ PON-Timer     → ErtsTimerInstigation│   │ pon_compiler.erl       │
│ PON-Scheduler → ErtsCondition      │   │ pon_runtime.erl       │
│ PON-Spawn     → notify hook        │   └──────────┬───────────────┘
│ PON-ETS       → PonEtsWatcher      │              │ gera Premises
│ PON-GC        → PonGcNode          │              ▼
└───────┬──────────────┬─────────────┘   ┌──────────────────────────┐
        │              │                 │ Harness & Verificação    │
        └──────────────┼────────────────►│ pon_harness / pon_diff  │
                       │                 │ TLA+ · Coq · Frama-C ·  │
                       │                 │ PropEr                  │
                       └────────────────►└──────────────────────────┘

Fase	Componente	Entidade PON	Mecanismo substituído	Ganho
1	PON-Receive	`ErtsPremise`	scan $O(N \times M)$ da mailbox	445× → 6.665×
2	PON-Timer	`ErtsTimerInstigation`	timer wheel polls	0% CPU ociosa; 10M× checagens
3	PON-Spawn	hook de notificação	agendamento passivo	~2×
4	PON-Scheduler	`ErtsCondition`	busy-spin	0% CPU ociosa; ~50× wakeup
5	PON-ETS	`PonEtsWatcher`	lock + busca	250× leituras; ~7× throughput
6	PON-Compiler	parse transform / SSA	recibos manuais	Premises nativas O(1)
7	PON-GC	`PonGcNode`	varredura de heap total	10× redução de scan

12. Verificação formal: as 4 pilastras

Ganhos assintóticos não são suficientes — semântica deve permanecer idêntica. O projeto sustenta que "trocar scan por notificação preserva a semântica exata do Erlang, sem deadlocks nem lost wakeups" com 4 pilastras matemáticas:

Pilastra	Ferramenta	Verifica
1. Model checking	TLA+/TLC	Invariantes do scheduler (`SchedulerWakeup.tla`, `ConditionNotify.tla`), mailbox (`MailboxPON.tla`, `PremiseMatch.tla`), timer (`TimerWheel.tla`), GC tri-color (`TriColorGC.tla`), lock-free (`AtomicLockFreeInvariants.tla`), sincronização distribuída (`DistributedNodeSync.tla`), equivalência do compilador (`CompilerSemanticsEquivalence.tla`)
2. Prova de teoremas	Coq	`TriColorGC.v` (segurança do GC) e `PONComplexity.v` (limites assintóticos O(1))
3. Análise estática/simbólica	Frama-C/ACSL e KLEE	Contratos de memória C e cobertura de caminhos LLVM
4. Teste de propriedades	PropEr	Equivalência estado-a-estado Stock vs PON

make verify-all   # TLA+ + PropEr + Frama-C
make verify-tla   # model checker TLC
make verify-proper
make verify-c

Quando eu, como engenheiro, digo "ecologia sem trade-offs", esta é a evidência: o radar holístico (idle CPU, mailbox, ETS, GC, spawn) mostra o PON-BEAM dominando em todos os eixos simultaneamente — ao contrário de otimizações clássicas que trocam uma dimensão por outra.

13. Como reproduzir você mesmo

git clone https://github.com/matheuscamarques/pon_beam.git
cd pon_beam
make build-stock        # OTP 30 baseline → /opt/erlang-30-stock
make build-pon          # PON-BEAM ERTS → /opt/erlang-30-pon
make build-pon-debug    # PON-BEAM com telemetria
make benchmark          # roda o harness diferencial completo
make benchmark-fase1    # só a fase 1
make report             # abre o HTML com os gráficos comparativos

Requisitos: Linux com kernel ≥ 4.18 (para eventfd/timerfd), GCC ≥ 9 / Clang ≥ 11, make/autoconf. Tudo roda também em Docker (make docker-build, make bench-docker).

14. Conclusão

O PON-BEAM responde a uma pergunta que a literatura NOP nunca tinha formulado: e se o paradigma de notificações fosse o projeto da máquina — e não apenas um estilo de aplicação?

Cada subsistema da BEAM foi convertido em entidade reativa:

Mailbox → Premises com advance O(1) do save pointer, sem scan linear (6.665×).
Timers → Instigações timerfd/epoll, o kernel conta o tempo por nós (0% CPU ociosa).
Scheduler → Conditions eventfd, o scheduler dorme de verdade (0% busy-spin).
ETS → watchers push em vez de lookups pull (250×).
GC → marcação tri-color por notificação, custo proporcional aos vivos (10×).
Compiler → parse transform que gera as Premises nativamente.

E, mais importante para a engenharia de VM: tudo sob #ifdef PON_BEAM, 100% retro-compatível, medido por benchmark diferencial e garantido por 4 pilastras formais. Não é uma otimização de constante — é uma inversão de complexidade assintótica.

"Changing how a virtual machine thinks is harder than building a new one — but forty years of compatibility legacy isn't built in a day." — Matheus de Camargo Marques, 2026

Referências

Repositório: github.com/matheuscamarques/pon_beam
Tese: docs/EX-37-pon-beam-arquitetura-orientada-a-notificacoes.md — PON-BEAM, a Notification-Oriented Virtual Machine Architecture
Plano de engenharia: docs/EX-38-pon-beam-plano-de-engenharia.md
Relatórios de fase: docs/RPT-01..RPT-10
Storytelling / saga técnica: docs/STORYTELLING.md
Paradigma PON: Simão & Stadzisz (2008–2009); Negrini (2019); Linhares (2015)
Código ERTS: otp/erts/emulator/beam/pon_{premise,condition,timer,ets,gc}.c e otp/erts/include/internal/pon_*.h

Este artigo acompanha o projeto de tese de **Matheus de Camargo Marques, licenciado sob Apache 2.0 (mesma licença do Erlang/OTP). Código de exemplo simplificado para legibilidade — o código real está no repositório com todas as guardas de segurança e validações.

I Re-Architected the Erlang VM Core in C to Eliminate O(N) Loops — The PON-BEAM Saga

Matheus de Camargo Marques — Wed, 05 Aug 2026 17:31:09 +0000

The history of concurrent computing features a golden chapter written at the Ericsson Computer Science Laboratory in the late 1980s. Erlang and its virtual machine, the BEAM, introduced the actor model at an industrial scale: millions of lightweight isolated processes exchanging messages without shared memory, fault-tolerant under the motto "Let It Crash".

However, beneath the elegance of the actor model lies an uncomfortable secret buried deep within the ERTS (Erlang Run-Time System) C engine: the virtual machine spends an immense quantity of CPU cycles asking whether things have changed.

To solve this, I developed PON-BEAM: a complete re-architecture of the Erlang/OTP 30 virtual machine in C. By applying the Notification-Oriented Paradigm (PON), we replaced forty years of legacy polling loops with a precise mesh of reactive notifications.

The Fundamental Flaw: The Cost of Polling

In traditional Erlang/OTP, critical runtime subsystems rely on procedural linear searches and active polling loops:

Selective Receive Scans: When a process executes a selective receive with M clauses and N pending messages, the VM executes up to N x M match trials. If a server accumulates 50,000 messages and a priority message matches at the tail, the BEAM traverses all preceding messages one by one.
Scheduler Spinning: Idle schedulers execute busy-wait loops to minimize wakeup latency, burning 5% to 30% of a CPU core in complete idleness just waiting for new processes.
Timer Wheel Scanning: Periodic wheel iterations to detect expired timers.
Garbage Collection Traversals: Semi-space scanning proportional to total heap size (O(heap)) rather than strictly active live objects.

The Solution: The Notification-Oriented Paradigm

The Notification-Oriented Paradigm (NOP), formulated by Prof. Dr. Jean Marcelo Simão, postulates that computation should not be structured around passive functions that are polled. Instead, it relies on reactive entities that evaluate themselves and actively notify interested dependents at the exact instant a state change occurs.

Instead of continuously asking "Has anything changed?", PON-BEAM inverts the control flow inside the ERTS C core using Linux kernel primitives like eventfd and epoll. The foundational entities are:

Premises: Entities evaluating elemental condition clauses and monitoring state updates.
Conditions: Logical collectors of Premises.
Instigations: Actions triggered atomically when a Condition is satisfied.

The Golden Rule: Surgical Isolation

Modifying a VM with decades of continuous evolution without breaking the regression test suite demands strict discipline. The core rule for PON-BEAM was that no original line of OTP code would be destroyed. All ERTS C modifications live enclosed within the preprocessor guard #ifdef PON_BEAM, ensuring 100% backward compatibility.

The 7 Structural Victories

By replacing linear scans with reactive notification meshes, PON-BEAM achieved significant asymptotic gains across all major runtime subsystems:

PON-Receive: Replaced O(N x M) mailbox scans with type-classified bucket queues and direct pon_in_link Premises. Selective receive latency dropped from 1,489 µs to 6 µs (a 248x speedup).
PON-Scheduler: Replaced scheduler spinning loops with eventfd and epoll_wait. Schedulers now sleep perfectly, dropping idle CPU consumption to 0.0%.
PON-ETS: Replaced repeated table lock lookups with lateral Watcher notifications, achieving 9,970,000 ops/sec (250x read acceleration).
PON-GC: Replaced full-heap scanning sweeps with Dijkstra Tri-Color incremental mark-by-notification. Scanning is now proportional to live objects (O(live)), reducing GC pause times by 10x.
PON-Timer: Replaced periodic Timer Wheel ticks with Linux timerfd Instigations.
PON-Spawn: Replaced passive process queue polling with active scheduling notifications.
PON-Compiler: Integrated a native SSA pass generating Premise matching bytecode directly.

Formal Verification Pipeline

Altering the low-level C codebase of a telecom-grade virtual machine risks introducing subtle race conditions or lost wakeups. To guarantee correctness, PON-BEAM includes a 4-pillar formal verification suite:

TLA+ / TLC Model Checker: Validating non-blocking invariants in the scheduler and mailbox specifications.
Coq Mechanized Proofs: Mechanized correctness of the Tri-Color GC propagation.
Frama-C / ACSL: C source-level contract verification ensuring memory safety and loop termination.
PropEr: Stateful equivalence property testing against stock OTP 30.

Conclusion

PON-BEAM proves that virtual machines do not need to poll. By replacing search loops with point-to-point notifications, the VM becomes dramatically more energy-efficient, reactive, and predictable.

You can run the full differential benchmark suite comparing baseline OTP 30 against the PON-BEAM build via Docker. Check out the repository, read the formal proofs, and run the benchmarks:

GitHub Repository: matheuscamarques/pon_beam

I would love to hear your thoughts on this architectural approach. What are the biggest bottlenecks you face when pushing BEAM to its limits? Let's discuss in the comments.

Modelo de Atores da BEAM vs. Scheduler Agent Supervisor: Mera Coincidência? O que a Ericsson com Erlang já resolveu no passado?

Matheus de Camargo Marques — Mon, 27 Jul 2026 17:08:02 +0000

Olá, me chamo Matheus de Camargo Marques. Ao aprofundar meus estudos em conceitos modernos de Cloud, deparei-me com o Scheduler Agent Supervisor pattern e tive uma sensação imediata de: "eu já vi isso antes".

Trazendo um contexto mais formal: se você trabalha com arquitetura de microsserviços distribuídos na nuvem moderna, certamente já se deparou com a necessidade de orquestrar sagas, gerenciar falhas transientes e garantir consistência eventual. O padrão Scheduler Agent Supervisor, documentado pelo Azure Architecture Center e teorizado originalmente por Clemens Vasters, propõe uma solução robusta combinando filas, bases de estado NoSQL e workers serverless.

Contudo, quando dissecamos os pilares de baixo nível da máquina virtual BEAM (o tempo de execução do Erlang e Elixir criado pela Ericsson na década de 1980), deparamo-nos com um fato estarrecedor: a nuvem moderna está recriando em macroescala de rede exatamente a mesma arquitetura que a BEAM já executa de forma nativa e em memória há mais de 40 anos. Neste artigo, analisamos desde a matemática do Modelo de Atores e os detalhes microscópicos em C da BEAM até a comparação quantitativa de latência, densidade computacional, custos financeiros e casos reais de empresas como WhatsApp, Bleacher Report e Discord.

1. O Paradoxo da Nuvem Moderna: A Reinvenção da Roda Distribuída

Em sistemas distribuídos contemporâneos, a falha não é um evento fortuito; é uma certeza estatística. Latência de rede flutuante, indisponibilidade temporária de bancos de dados, gargalos de I/O e exaustão de memória não são anomalias, mas condições operacionais cotidianas.

Para sobreviver a esse ambiente caótico, os arquitetos de nuvem abraçaram o padrão Scheduler Agent Supervisor. A proposta é elegante em teoria:

O Scheduler (Agendador): Mantém o estado da transação (workflow) em uma base de dados durável e dispara etapas via filas de mensagens.
O Agent (Agente): Executa uma regra de negócio isolada (ex: uma função Serverless ou container) e notifica o Scheduler sobre o sucesso.
O Supervisor: Um processo que corre periodicamente em background (polling via cron) inspecionando o banco de dados em busca de tarefas órfãs ou estouradas por timeout, tomando medidas de re-tentativa (retry) ou acionando transações compensatórias.

Porém, ao implementar essa arquitetura no Azure ou AWS, o desenvolvedor precisa colar pelo menos quatro serviços gerenciados distintos (Azure Functions / AWS Lambda, Service Bus / SQS, CosmosDB / DynamoDB, e sistemas de Leader Election).

A pergunta inevitável é: Por que a engenharia de software precisa montar uma infraestrutura física tão pesada e cara para atingir a resiliência que o Erlang e a BEAM entregavam dentro de um único processo de máquina virtual nos anos 80?

2. Fundamentos Teóricos: De Carl Hewitt à Ericsson de 1986

Para entender por que a BEAM é imune à maioria das dores de cabeça dos sistemas distribuídos modernos, precisamos retornar às suas origens matemáticas e industriais.

2.1 O Modelo de Atores (Carl Hewitt, 1973)

Proposto no MIT por Carl Hewitt, Peter Bishop e Richard Steiger, o Modelo de Atores rejeitou o modelo sequencial da Máquina de Turing. Ele postula que o bloco fundamental da computação é o Ator:

Uma entidade isolada que encapsula estado, comportamento e processamento.
Comunica-se exclusivamente por passagem de mensagens assíncronas.
Ao receber uma mensagem, um ator só pode fazer três coisas: criar novos atores, enviar mensagens a atores conhecidos (via PID) e designar o comportamento para a próxima mensagem.

O trunfo absoluto do Modelo de Atores é a ausência total de memória compartilhada. Sem memória compartilhada, a BEAM eliminou de uma só vez as maiores pragas do desenvolvimento concorrente: trincos (locks), semáforos, condições de corrida (race conditions) e impasses circulares (deadlocks).

2.2 A Necessidade da Ericsson e os "Nine Nines"

Na década de 1980, Joe Armstrong, Robert Virding e Mike Williams pesquisavam nos laboratórios da Ericsson como construir os comutadores telefônicos (switches) da série AXE. Os requisitos eram colossais:

Suportar centenas de milhares de chamadas concorrentes;
Permitir atualização de código sem parar o sistema (hot code reloading);
Atingir 99,9999999% de disponibilidade (o lendário padrão de 9 noves).

A resposta foi a criação do Erlang e da plataforma OTP (Open Telecom Platform), rodando sobre a máquina virtual BEAM.

2.3 A Filosofia "Let it Crash" vs. Programação Defensiva

Na sua tese de doutorado em 2003 ("Making reliable distributed systems in the presence of software errors"), Joe Armstrong criticou severamente a programação defensiva tradicional.

Em linguagens como Java, C# ou Python, os desenvolvedores cercam o código com blocos try/catch gigantescos tentando prever exceções. O problema é que, ao capturar uma exceção imprevista, o processo continua rodando com estado volátil corrompido, gerando vazamento de memória ou corrupção de banco.

Armstrong defendeu o oposto:

"Se um processo encontrar um estado anômalo, não tente adivinhar como se recuperar. Morra imediatamente. Deixe que um processo supervisor limpo cuide da recuperação."

Como os processos BEAM são totalmente isolados, o colapso de um ator não afeta a memória dos vizinhos. O Supervisor, imune ao erro por não executar regras de negócio, detecta a morte do processo e o reinicia a partir de um estado estável e garantido.

3. Mapeamento Arquitetural: Cloud Padrão SAS vs. Primitivas BEAM

A tabela a seguir demonstra a equivalência direta entre a infraestrutura montada na nuvem e o que já vem embutido nativamente na máquina virtual BEAM:

Padrão Cloud (Azure / AWS)	Equivalente Nativo BEAM (Elixir / Erlang OTP)
Agendador (Durable Functions / Step Functions)	`gen_statem` (Máquina de Estados) / `GenServer`
Agente (Lambda / Azure Function / Container)	Processo Ator verde em RAM (~2,4 KB de pegada)
Fila de Mensagens (Service Bus / SQS)	Mailbox interna lock-free do processo BEAM
Banco de Estado (CosmosDB / DynamoDB)	Heap privado local, Tabelas ETS ou Mnesia
Supervisor (Cron Polling + DLQ)	Árvore de Supervisão reativa (Links e Monitors)

A Grande Diferença: Polling em Rede vs. Sinalização Reativa

No padrão de nuvem, o Supervisor precisa rodar uma rotina agendada (CRON) que faz queries periódicas no banco de dados para checar se algum agente estourou o prazo (LockedUntil). Isso gera consumo desnecessário de I/O e latência na detecção da falha.

Na BEAM, a supervisão é puramente reativa. Quando um processo filho falha, a própria máquina virtual emite instantaneamente um sinal de interrupção (:EXIT) via links ou monitors diretamente para o processo Supervisor. A recuperação ocorre em microssegundos, sem despesa com chamadas de rede ou consultas a bancos.

4. Anatomia Microscópica da BEAM: O Subsolo da VM em Código C

Para entender como a BEAM dispensa a infraestrutura pesada da nuvem, precisamos olhar para as especificações internas do seu motor. Tudo se resume a como o tempo de execução em linguagem C (erl_process.h) gerencia a memória física de forma isolada.

4.1 O Process Control Block (PCB)

Cada ator Erlang é representado internamente pela estrutura C process (referenciada pelo ponteiro c_p). Enquanto uma thread nativa de sistema operacional aloca entre 512 KB e 8 MB de memória, a criação de um processo BEAM consome apenas 327 a 338 palavras (words) — aproximadamente 2,5 a 3 KB em arquiteturas de 64 bits.

O PCB aloja os metadados essenciais:

id (PID): Um identificador de 28 bits que segmenta o índice da tabela de processos, um número de série de 13 bits (que impede a reutilização imediata de PIDs de processos mortos) e o nó do cluster distribuído.
Apontadores de Memória (stop / htop / hend): Salvaguardam o topo da pilha e do monte. Durante a execução, esses valores são mantidos diretamente nos registradores físicos da CPU através do compilador JIT (introduzido no Erlang/OTP 24, que proporcionou um ganho de performance massivo e consolidou a BEAM para tarefas de alto processamento).
Filas de Sinalização (sig_inq / sig_qs): A caixa de correio externa lock-free e a fila de entrada.
ErlOffHeap: A estrutura que ancora a lista MSO para gerenciamento de binários globais.

4.2 A Física da Memória Privada: Crescimento Bidirecional

Diferente de outras linguagens que alocam áreas soltas de memória exigindo chamadas pesadas ao SO (malloc), a BEAM aloca um único bloco contíguo de memória privada para cada processo:

+-----------------------------------------------------------------------+
|  Endereço Baixo                                       Endereço Alto   |
|  [ HEAP (Cresce para CIMA ^) ]  ---> <--- [ STACK (Cresce para BAIXO v) ]|
|  |--- htop ------------------------ stop (E) ------------------------|
+-----------------------------------------------------------------------+
                                   ^
                           Ponto de Colisão
                        (Dispara o GC Isolado)

O Heap (Cresce para cima): Armazena estruturas dinâmicas como listas consulares (2 words por nó), tuplas, inteiros grandes e floats.
O Stack (Cresce para baixo): Armazena registradores, variáveis locais e o Ponteiro de Continuação (CP) via instrução allocate.

Quando o topo do heap (htop) colide com a base da pilha (stop), a BEAM sabe no exato milissegundo que a memória local acabou. Isso dispara uma rotina de Garbage Collection per-processo, totalmente isolada.

4.3 Garbage Collection de Cheney Per-Processo (Zero Stop-The-World)

Na JVM ou no Go, o Garbage Collector precisa analisar o estado global da aplicação, o que frequentemente aciona as temidas pausas Stop-The-World (onde toda a aplicação congela por milissegundos).

Na BEAM, não existe Garbage Collector global. Cada processo possui seu próprio GC independente baseado no Algoritmo de Cópia de Cheney:

Os dados vivos são copiados do From-Space para um novo To-Space, desfragmentando listas para maximizar a localidade de cache da CPU.
O espaço antigo é descartado de uma vez só.
Os dados sobreviventes ultrapassam o ponteiro high_water e são promovidos ao Old Heap.

Se um processo é de curta duração (ex: atende uma requisição e morre), ele é destruído junto com toda a sua memória privada de uma só vez, sem sequer precisar acionar o Garbage Collector!

4.4 Taxonomia Avançada de Binários e a Lista MSO List

Copiar grandes payloads (como arquivos JSON de 10 MB ou imagens) entre atores destruiria a performance. Para resolver isso, a BEAM categoriza os binários em quatro tipos:

Heap Binary ($\le 64$ bytes): Fica diretamente no heap privado do ator.
Refc Binary ($> 64$ bytes): Fica fora dos processos, no Binary Heap Global. É gerenciado por Contagem de Referências (Reference Counting).
Sub Binary: Um slice/offset apontando para um Refc Binary sem duplicar bytes.
Match Context: Ponteiro de estado efêmero para Pattern Matching.

Quando dois atores trocam um binário grande (Refc Binary), a BEAM copia apenas o ProcBin (um pequeno descritor de 5 palavras no heap privado) e incrementa atomicamente o contador global. A estrutura ErlOffHeap no PCB mantém a MSO List (Mark and Sweep Object List): quando o GC privado do processo limpa o ProcBin morto, ele decrementa atomicamente a referência no Binary Heap Global.

5. Concorrência Extrema, Lock-Free e o Motor de 2000 Reduções

5.1 Fila de Entrada Lock-Free (`sig_inq`) e `message_queue_data = :off_heap`

Para suportar milhares de emissores enviando mensagens para o mesmo ator sem bloqueios, a BEAM utiliza uma fila de entrada externa totalmente lock-free (sig_inq).

Sob torrentes brutais de mensagens, a BEAM permite configurar o processo com a flag message_queue_data = :off_heap. Nesse modo, as mensagens recebidas permanecem na fila exterior, sem passar pelo Garbage Collector geracional do ator, e só são fundidas à memória privada no momento exato em que a cláusula receive faz um Pattern Match. Isso impede que servidores fiquem lentos por causa de mensagens acumuladas.

5.2 O Motor Escalonador (2000 Reduções)

Ao contrário do Go (onde o escalonador cooperativo dependia originalmente de pontos de checagem manuais) ou da JVM (que depende das threads pesadas do SO), a BEAM adota uma preempção cooperativa a nível C (process_main em beam_emu.c).

A BEAM aloca exatamente 1 Thread Escalonadora por núcleo físico/lógico da CPU ($N:M$).
Cada processo recebe um orçamento estrito de 2000 Reduções (time slice budget).
Cada chamada de função, BIF (Built-in Function) ou passo de GC decrementa o contador.
Ao chegar a 0 reduções, o processo sofre um Yield Point: salvaguarda seus registradores no Stack/PCB e cede o lugar voluntariamente na Run Queue.

Isso garante equidade perfeita e resposta Soft Real-Time: nenhuma rotina de usuário consegue monopolizar a CPU ou travar os outros atores.

5.3 Task Stealing, Dirty Schedulers e Erlang Monotonic Time

Task Stealing: Escalonadores ociosos roubam processos runnable das filas de núcleos sobrecarregados.
Dirty Schedulers (CPU_BOUND / IO_BOUND): Isolam chamadas pesadas em C/Rust (NIFs) em threads separadas, impedindo que funções C sem reduções parem o tempo de execução da VM.
Erlang Monotonic Time & Time Warp: A BEAM desvincula seu tempo interno do relógio POSIX de parede. Se o relógio do SO for alterado via NTP, a BEAM aplica uma dilatação imperceptível de até 1% na frequência de seu relógio interno, evitando saltos bruscos que quebrariam timeouts e cronômetros de supervisão.

6. A Metáfora Bio-Inspirada: O Sistema de Memória Cognitiva

Podemos entender a arquitetura da BEAM e o padrão Cloud através da lente da Neurociência e dos Sistemas de Memória Cognitiva:

Memória de Curto Prazo (STM / Working Memory): No córtex pré-frontal, mantém a informação volátil ativa. Na BEAM, é o heap isolado do GenServer e a caixa de correio. Na nuvem, é o contexto em RAM de uma Função Lambda.
Memória de Longo Prazo (LTM / Consolidada): O hipocampo consolida informações duráveis no neocórtex. Na BEAM, é o banco de dados in-memory ETS, o Mnesia ou o Postgres. Na nuvem, é o CosmosDB/DynamoDB.
Homeostase e Reidratação (Supervisão e Recall): Diante de um estresse ou trauma (crash), a homeostase do organismo restaura o equilíbrio. Na BEAM, a Árvore de Supervisão captura a morte do processo, consulta a LTM (ETS/Mnesia) e reidrata o ator com o último estado consolidado em microssegundos.

7. A Matemática Implacável: Latência, Densidade e Custos Financeiros

Para o arquiteto de software, a teoria precisa ser respaldada por números. Vamos comparar as duas abordagens em três eixos críticos:

7.1 A Matemática da Latência (Tempo)

Nuvem (Pulos de Rede): Em uma arquitetura Cloud SAS, cada interação entre o Scheduler, a Fila, a Função Serverless e o CosmosDB cruza a rede do datacenter. Mesmo otimizado com gRPC (cerca de 130 µs), cada salto leva entre 0,5 ms e 1,0 ms. O ciclo completo de uma etapa consome de 2 ms a 50 ms.
BEAM (Troca de Mensagens em RAM): O envio de uma mensagem entre dois atores na mesma VM ocorre via cópia de ponteiros em RAM, levando aproximadamente 1 µs — ou seja, 1000 vezes mais rápido que a nuvem.

7.2 Densidade Computacional (Memória)

Modelos Tradicionais (Threads de SO): Cada thread em Java ou C# consome ~1 MB de RAM. Um servidor típico começa a passar mal com poucas dezenas de milhares de conexões simultâneas.
BEAM (Green Threads): Com uma pegada inicial de ~2,4 KB (309 words), um único servidor bare-metal consegue rodar confortavelmente centenas de milhares a milhões de atores simultâneos.

7.3 A Matemática dos Custos Financeiros (Dinheiro)

Nuvem Serverless (Faturamento Microtransacional): Você paga por cada requisição HTTP, cada invocação de Lambda, cada leitura/escrita em filas (SQS/Service Bus), cada RU (Request Unit) do CosmosDB e pelo tráfego de saída (Egress). Se a aplicação receber 50 milhões de acessos no day, a fatura estoura.
BEAM em Servidor Dedicado / VPS (Custo Fixo): Um monólito distribuído (Majestic Monolith) em Elixir roda em uma máquina virtual (VPS) de US$ 40/mês. Processar 1 milhão ou 1 bilhão de mensagens internamente nessa máquina custará exatamente os mesmos US$ 40 no final do mês.

8. Evidências Empíricas da Indústria (Casos de Estudo)

A superioridade teórica da BEAM é comprovada pelos casos históricos das maiores plataformas do planeta:

Plataforma	Arquitetura Adotada	Resultado Métrico
WhatsApp	Erlang c/ Atores por Usuário + Mnesia + Kernel FreeBSD ajustado (`kern.ipc.maxsockets = 2.4M`)	> 2 Milhões conexões ativas por servidor. Apenas 50 engenheiros para 2 bilhões de usuários.
Bleacher Report	Migração de Ruby on Rails para Elixir / Phoenix	Redução brutal de 150 instâncias AWS EC2 para apenas 5 servidores nos picos de tráfego.
Discord	Elixir (WebSockets) + Rust NIFs (Rustler) substituindo Go no serviço Read States	Latência despencou de 27.000 µs (pausas de GC do Go) para 4 µs com > 11M conexões.

8.1 WhatsApp: 2 Milhões de Conexões por Servidor

O WhatsApp sustentou mais de 2 bilhões de usuários ativos com um time de infraestrutura de apenas 50 engenheiros.

Como? Criando 1 Ator Erlang por usuário conectado. Com a pegada de 2 KB por processo, milhões de conexões permaneceram ativas na memória RAM.
Tuning de Kernel: Ajustaram o kernel FreeBSD (kern.ipc.maxsockets = 2.400.000 e kern.maxfiles = 3.000.000), atingindo o recorde histórico de mais de 2 milhões de conexões TCP ativas em um único servidor bare-metal com 85% de uso de CPU.

8.2 Bleacher Report: De 150 para 5 Servidores na AWS

O Bleacher Report sofria com picos de acessos durante transmissões de eventos esportivos. A arquitetura original em Ruby on Rails não aguentava o tráfego devido ao bloqueio do GIL (Global Interpreter Lock).

Ao migrar o sistema para Elixir e Phoenix, a empresa reduziu a sua infraestrutura na AWS de 150 instâncias EC2 para apenas 5 servidores, economizando milhões de dólares.

8.3 Discord: De 27.000 µs para 4 µs de Latência (Go vs. Rust/Elixir)

O Discord opera mais de 11 milhões de usuários simultâneos em WebSockets controlados pelo Elixir.

O serviço Read States (que rastreia mensagens lidas) foi escrito originalmente em Go. Porém, a cada 2 minutos (120s), o Garbage Collector global do Go acionava um mark-and-sweep, gerando picos de latência de 27.000 µs (27 ms).
A engenharia reescreveu o núcleo do serviço em Rust, integrando-o ao Elixir via NIFs (Rustler). A latência caiu de 27.000 µs para 4 µs, sem abrir mão das Árvores de Supervisão do Elixir.

9. Conclusão: Coincidência ou Sabedoria Esquecida?

O padrão Scheduler Agent Supervisor promovido pelos provedores de nuvem modernos não é uma mera coincidência — é a prova inequívoca de que os desafios da computação distribuída são universais. A nuvem chegou às mesmas conclusões que Joe Armstrong e a equipe da Ericsson chegaram em 1986.

A diferença fundamental reside no nível de abstração:

A Nuvem tenta resolver o problema colando peças de infraestrutura pela rede (filas, bancos de dados, lambdas, CRONs), pagando um imposto altíssimo em latência, complexidade operacional e custos financeiros.
A BEAM resolve o problema no nível da linguagem e do tempo de execução, utilizando a memória RAM, processos verdes, contagem de reduções e supervision trees reativas.

Se a sua empresa opera microsserviços em nuvem e sofre com custos astronômicos de Serverless, latências de rede acumuladas ou complexidade excessiva de orquestração, talvez seja hora de parar de tentar recriar a BEAM com infraestrutura de nuvem... e simplesmente começar a usar a BEAM.

Vamos Continuar a Conversa?

E você, já enfrentou desafios de latência acumulada ou custos astronômicos de infraestrutura ao orquestrar microsserviços na nuvem? Já experimentou o Modelo de Atores no Elixir ou Erlang?

Fique à vontade para deixar suas impressões, dúvidas ou relatar suas experiências nos comentários! Se quiser explorar projetos onde aplico esses conceitos na prática — desde agentes bio-inspirados e pipelines RAG até web crawlers de altíssima performance —, confira meus repositórios no GitHub ou conecte-se comigo no LinkedIn.

A nuvem chegou às mesmas conclusões que Joe Armstrong e a equipe da Ericsson chegaram em 1986.

Matheus de Camargo Marques — Mon, 27 Jul 2026 17:06:58 +0000

A nuvem chegou às mesmas conclusões que Joe Armstrong e a equipe da Ericsson chegaram em 1986.

Trazendo um contexto mais formal: nos últimos dez anos, a engenharia de software presenciou uma corrida frenética em direção aos microsserviços, arquiteturas orientadas a eventos e padrões sofisticados de resiliência como o Scheduler Agent Supervisor, Sagas, Circuit Breakers e Dead-Letter Queues. Fornecedores de nuvem como Microsoft Azure e AWS investiram bilhões promovendo ferramentas gerenciadas para orquestrar falhas de rede e consistência eventual.

No entanto, quando despimos essa infraestrutura da sua roupagem comercial, chegamos a uma constatação histórica fascinante: a nuvem moderna passou quatro décadas reinventando a roda para entregar, via rede, os mesmos princípios que Joe Armstrong, Robert Virding e Mike Williams implementaram dentro da máquina virtual BEAM (Erlang/OTP) em 1986. Este artigo demonstra como a convergência da arquitetura em nuvem valida as decisões históricas da Ericsson e por que entender a BEAM é o maior atalho para projetar sistemas verdadeiramente escaláveis e econômicos hoje.

1. A Grande Convergência Arquitetural

Se você observar o diagrama de arquitetura de uma aplicação moderna resiliente na nuvem (Azure ou AWS), encontrará uma topologia bastante padronizada:

Um orquestrador de estado (Azure Durable Functions ou AWS Step Functions);
Uma fila de mensagens para desacoplar a comunicação (Azure Service Bus ou AWS SQS);
Agentes de execução epêmeros (Azure Functions, AWS Lambda ou containers Docker);
Um banco de dados NoSQL durável para guardar checkpoints do fluxo (CosmosDB ou DynamoDB);
Um mecanismo de supervisão em background (Cron jobs ou Dead-Letter Queues) para detectar tarefas expiradas e disparar re-tentativas ou transações compensatórias.

Esse arranjo é formalmente chamado de padrão Scheduler Agent Supervisor.

Mas se você apresentar essa mesma arquitetura a um desenvolvedor Erlang ou Elixir veterano, a resposta dele será um sorriso irônico:

"Espere um pouco... você montou quatro serviços gerenciados na nuvem, com dezenas de chamadas de rede, serialização JSON e custos por requisição, apenas para reproduzir o que um GenServer, um Supervisor e uma tabela ETS fazem nativamente na memória da BEAM desde a década de 80?"

A nuvem não inventou uma nova ciência de sistemas distribuídos. Ela apenas re-descobriu na rede os axiomas que a Ericsson provou no nível do tempo de execução (runtime).

2. A História Se Repete: O Problema da Ericsson nos Anos 80

Para entender por que a BEAM acertou há 40 anos, precisamos olhar para o problema que Joe Armstrong e sua equipe precisavam resolver nos laboratórios da Ericsson em Estocolmo.

O Desafio dos Comutadores Telefônicos AXE

Nos anos 80, a Ericsson construía as centrais telefônicas da série AXE. Os requisitos não eram muito diferentes do que exigimos hoje das maiores plataformas digitais do mundo:

Concorrência Massiva: Milhares de ligações telefônicas simultâneas, cada uma com seu próprio estado.
Zero Downtime: O sistema não podia parar sob nenhuma hipótese.
Hot Code Reloading: Atualizar o código do sistema com chamadas em andamento sem derrubar conexões.
Resiliência Absoluta: O lendário limiar de 99,9999999% de disponibilidade (nine nines), correspondendo a menos de 1 segundo de inatividade em décadas.

O Modelo de Atores (Carl Hewitt, 1973) na Prática

Para atingir esse nível de tolerância a falhas, a equipe abandonou a programação imperativa tradicional e o modelo de memória compartilhada. Adotaram o Modelo de Atores teorizado por Carl Hewitt no MIT em 1973.

No Erlang:

Tudo é um processo (Ator): Não uma thread pesada do sistema operacional, mas um processo verde (green thread) ultraleve gerido pela máquina virtual.
Isolamento Absoluto de Memória: Cada processo possui sua própria pilha (stack) e seu próprio monte (heap). Não existem variáveis compartilhadas.
Passagem de Mensagens Assíncronas: A comunicação ocorre enviando mensagens para a caixa de correio (mailbox) do processo de destino via seu Identificador de Processo (PID).

Sem memória compartilhada, a BEAM eliminou de uma só vez as maiores pragas do desenvolvimento concorrente: trincos (locks), semáforos, condições de corrida (race conditions) e impasses circulares (deadlocks).

A Virada Filosófica: "Let it Crash"

Joe Armstrong, em sua tese de doutorado de 2003 ("Making reliable distributed systems in the presence of software errors"), formalizou a filosofia que se tornaria a assinatura do Erlang: "Let it Crash" (Deixe Quebrar).

Em linguagens tradicionais (Java, C#, Python), ensina-se a programação defensiva: encher o código de blocos try/catch para capturar exceções. O problema é que, ao capturar uma exceção imprevista, o processo continua rodando com dados corrompidos na memória.

Armstrong defendeu o oposto:

"Se um processo encontrar um estado anômalo, não tente adivinhar como se recuperar. Morra imediatamente. Deixe que um processo supervisor limpo cuide da recuperação."

3. Anatomia da Reinvenção: O Mapeamento Peça por Peça

Ao compararmos o padrão nativo da nuvem com as primitivas da BEAM, a equivalência é ponto por ponto:

Padrão Cloud (Azure / AWS)	Equivalente Nativo BEAM (Elixir / Erlang OTP)
Agendador (Durable Functions / Step Functions)	`gen_statem` (Máquina de Estados) / `GenServer`
Agente (Lambda / Azure Function / Container)	Processo Ator verde em RAM (~2,4 KB de pegada)
Fila de Mensagens (Service Bus / SQS)	Mailbox interna lock-free do processo BEAM
Banco de Estado (CosmosDB / DynamoDB)	Heap privado local, Tabelas ETS ou Mnesia
Supervisor (Cron Polling + DLQ)	Árvore de Supervisão reativa (Links e Monitors)

O Detetor de Anomalias: Polling em Rede vs. Sinalização Reativa

Aqui reside uma das diferenças mais dramáticas entre a nuvem e a BEAM.

No padrão Cloud SAS, o Supervisor precisa rodar uma rotina agendada (CRON) que faz queries periódicas no CosmosDB em busca de registros onde o tempo limite (LockedUntil) expirou sem confirmação. Isso consome ciclos de leitura no banco de dados, gera tráfego de rede desnecessário e introduz atrasos na detecção da falha.

Na BEAM, a supervisão é puramente reativa e em tempo real. A máquina virtual conecta o processo filho ao Supervisor usando primitivas de baixo nível chamadas links e monitors. Se o filho colapsa, a própria VM emite um sinal de morte (:EXIT) direto para a caixa de correio do Supervisor em microssegundos. A recuperação é instantânea, sem nenhuma chamada de rede ou polling.

4. Por Baixo do Capô da BEAM: A Física da Memória e o Código C

4.1 O Process Control Block (PCB)

Cada ator Erlang é representado internamente pela estrutura C process (ponteiro c_p).

Pegada de Memória: A criação de um processo BEAM exige apenas 327 a 338 palavras (words) — aproximadamente 2,5 a 3 KB em sistemas de 64 bits. Em comparação, uma thread nativa de sistema operacional aloca entre 512 KB e 8 MB.
PID de 28 bits: O identificador aloja 15 bits para índice de tabela, 13 bits para número de série (evitando reuso de PIDs mortos) e a identificação do nó distribuído.
Registradores e JIT: Durante a execução, os apontadores de memória do processo são mantidos diretamente nos registradores físicos da CPU através do compilador JIT (introduzido no Erlang/OTP 24, que proporcionou um ganho de performance massivo e consolidou a BEAM para tarefas de alto processamento).

4.2 Crescimento Bidirecional: Stack vs. Heap Contíguos

A BEAM aloca um único bloco contíguo de memória privada para cada processo:

+-----------------------------------------------------------------------+
|  Endereço Baixo                                       Endereço Alto   |
|  [ HEAP (Cresce para CIMA ^) ]  ---> <--- [ STACK (Cresce para BAIXO v) ]|
|  |--- htop ------------------------ stop (E) ------------------------|
+-----------------------------------------------------------------------+
                                   ^
                           Ponto de Colisão
                        (Dispara o GC Isolado)

O Heap cresce para cima (armazenando listas, tuplas e floats). O Stack cresce para baixo (armazenando o fluxo do programa e quadros de funções).

Quando o topo do heap (htop) se cruza com a base da pilha (stop), a máquina virtual detecta o ponto exato de exaustão e aciona o Garbage Collection per-processo.

4.3 Zero Stop-The-World: O GC de Cheney Per-Processo

Linguagens como Java e Go sofrem com o problema do Garbage Collector global. Quando o GC precisa limpar a memória, a aplicação inteira é paralisada (Stop-The-World pause).

Na BEAM, não existe Garbage Collector global. Cada processo possui seu próprio GC independente baseado no Algoritmo de Cópia de Cheney:

Os dados vivos são copiados do From-Space para o To-Space, alinhando estruturas para maximizar a localidade no cache da CPU.
Os sobreviventes passam pela marca d'água (high_water) e são promovidos ao Old Heap.
Se um processo é de curta duração (ex: atende uma requisição e morre), ele é destruído com toda a sua memória privada de uma só vez, sem sequer rodar o Garbage Collector.

4.4 Refc Binaries e a Lista MSO List

Para evitar a cópia pesada de payloads grandes (como JSONs de 10 MB) entre atores, a BEAM classifica os binários:

Binários curtos ($\le 64$ bytes) ficam no heap privado do processo (Heap Binary).
Binários longos ($> 64$ bytes) ficam no Binary Heap Global (Refc Binary), gerenciados por contagem de referências.

Quando dois processos trocam um binário grande, a BEAM copia apenas um descritor de 5 palavras chamado ProcBin e incrementa o contador global de referências. A lista MSO (Mark and Sweep Object List) ancorada na estrutura ErlOffHeap do PCB garante que, quando o processo morre, a referência no Binary Heap Global é decrementada de forma atômica.

4.5 Preempção Cooperativa: O Orçamento de 2000 Reduções

Em beam_emu.c, o loop principal do emulador (process_main) executa os processos atribuindo a cada um um orçamento fixo de 2000 Reduções (time slice budget).

Cada chamada de função, operação de I/O ou passo de GC decrementa o contador. Ao chegar a zero reduções, o processo sofre um Yield Point: salvaguarda seus registradores no PCB e cede o lugar voluntariamente na Run Queue.

Isso garante resposta Soft Real-Time: nenhum processo de usuário, por mais complexo que seja, consegue monopolizar a CPU ou travar os outros atores.

5. O Modelo Cognitivo Bio-Inspirado: Memória & Homeostase

A arquitetura da BEAM e os padrões de resiliência distribuída podem ser interpretados através dos princípios da Neurociência Cognitiva:

Memória de Curto Prazo (STM / Working Memory): Onde o foco atencional reside. Na BEAM, é o estado efêmero do GenServer na memória RAM.
Memória de Longo Prazo (LTM / Consolidada): Onde os fatos são preservados permanentemente. Na BEAM, são as tabelas in-memory ultra-rápidas ETS, o banco de dados distribuído Mnesia ou a camada de persistência relacional (Postgres/Ecto).
Homeostase e Reidratação: Quando o organismo sofre um choque (crash do ator), a Homeostase aciona o mecanismo de resgate. A Árvore de Supervisão reinicia o ator e faz o recall da LTM, reidratando a Memória de Trabalho em microssegundos sem deixar o sistema em estado corrompido.

6. A Matemática da Nuvem vs. A Matemática da BEAM

Quando colocamos as duas abordagens na ponta do lápis, a diferença de eficiência é assustadora:

1. Latência (Tempo)

Nuvem (Pulos de Rede): Cada transição de estado entre a Fila, o Agente, o Scheduler e o Banco de Dados exige uma travessia pela rede do datacenter. Mesmo com gRPC (cerca de 130 µs), cada salto leva entre 0,5 ms e 1 ms. Uma etapa completa consome de 2 ms a 50 ms.
BEAM (Memória RAM): A troca de mensagens entre atores ocorre por cópia de ponteiros na própria RAM do servidor. A latência é de 1 µs — 1000 vezes mais rápida que a nuvem.

2. Densidade Computacional (Memória)

Threads de SO (Java / C#): Consomem ~1 MB de RAM por thread. O servidor satura com poucas dezenas de milhares de conexões.
Atores BEAM: Consomem ~2,4 KB. Um único servidor básico comporta centenas de milhares a milhões de atores concorrentes.

3. Custo Financeiro (Dinheiro)

Nuvem Serverless: Cobrança por invocação de função + tempo de execução em ms + leituras/escritas na fila + unidades de requisição (RUs) no CosmosDB + tráfego Egress. Em alta escala, a conta é punitiva.
BEAM em VPS / Dedicado: Monólito distribuído em Elixir rodando em uma instância VPS de US$ 40/mês. O custo permanece rigorosamente os mesmos US$ 40/mês, quer o sistema processe 1 milhão ou 1 bilhão de mensagens.

7. Evidências Empíricas da Indústria

Três casos emblemáticos da história recente do software comprovam o impacto prático dessa arquitetura:

Plataforma	Arquitetura Adotada	Resultado Métrico
WhatsApp	Erlang c/ Atores por Usuário + Mnesia + Kernel FreeBSD ajustado (`kern.ipc.maxsockets = 2.4M`)	> 2 Milhões conexões ativas por servidor. Apenas 50 engenheiros para 2 bilhões de usuários.
Bleacher Report	Migração de Ruby on Rails para Elixir / Phoenix	Redução brutal de 150 instâncias AWS EC2 para apenas 5 servidores nos picos de tráfego.
Discord	Elixir (WebSockets) + Rust NIFs (Rustler) substituindo Go no serviço Read States	Latência despencou de 27.000 µs (pausas de GC do Go) para 4 µs com > 11M conexões.

WhatsApp: Com um ator Erlang dedicado a cada conexão de usuário (pegada de 2 KB) e pequenos ajustes de sysctl no FreeBSD (kern.ipc.maxsockets = 2.400.000), a empresa manteve mais de 2 milhões de conexões TCP ativas por servidor bare-metal. Apenas 50 engenheiros mantinham a infraestrutura para 2 bilhões de usuários.
Bleacher Report: O portal de esportes encolheu sua frota de servidores na AWS de 150 instâncias EC2 (Ruby on Rails) para apenas 5 servidores ao migrar para Elixir e Phoenix, eliminando dependências externas pesadas de cache e mensageria.
Discord: Gerencia mais de 11 milhões de usuários concorrentes em WebSockets mantidos pelo Elixir. Ao substituir um microserviço em Go (que sofria pausas de GC de 27.000 µs a cada 2 minutos no serviço Read States) por uma NIF em Rust conectada ao Elixir (Rustler), a latência despencou para 4 µs.

8. Conclusão: O Futuro Pertence a Quem Entende a História

A nuvem moderna não inventou a tolerância a falhas nem a orquestração distribuída. Ela apenas abraçou as conclusões que Joe Armstrong e a equipe da Ericsson consolidaram em 1986.

A diferença crucial é que a nuvem vende essa resiliência como um amontoado de serviços pagos por requisição e conectados pela rede, enquanto a BEAM entrega o mesmo rigor dentro de um tempo de execução coeso, elegante e extremamente rápido.

Para os arquitetos e engenheiros de software modernos, a lição é clara:

Se você está projetando um sistema concorrente e de alta disponibilidade, não precisa remontar a BEAM com dezenas de microsserviços e filas.
Olhar para o passado do software e aprender com quem resolveu a concorrência na década de 80 é o caminho mais rápido, sustentável e lucrativo para construir o futuro da tecnologia.

Vamos Continuar a Conversa?

E você, já enfrentou desafios de latência acumulada ou custos astronômicos de infraestrutura ao orquestrar microsserviços na nuvem? Já experimentou o Modelo de Atores no Elixir ou Erlang?

A Filosofia Oculta das Ferramentas (Agente ou a gente ?)

Matheus de Camargo Marques — Wed, 22 Jul 2026 19:23:38 +0000

Olá, pessoal! Espero que estejam tendo um ótimo dia. Me chamo Matheus de Camargo Marques e o texto a seguir deriva de alguns devaneios que costumo ter durante meus estudos. Costumo transitar por temas que vão desde a matemática para machine learning até a filosofia de Sêneca, e meu olhar para as ferramentas raramente se detém na superfície do 'o que é'. Meu foco é sempre investigar qual é a carga conceitual que aquela ferramenta carrega por debaixo do capô.

Confesso: a vida seria muito mais tranquila se eu simplesmente aceitasse as coisas como elas são. Essa busca incessante para compreender a fundo os conceitos sobrecarrega qualquer um. Mas, para mim, ela traz uma recompensa inestimável que chamo de 'alívio cognitivo'. Enquanto eu não destrincho a verdadeira natureza de um assunto, minha mente simplesmente não desliga. Por mais que essa intensidade se aproxime muito das características de Altas Habilidades e Superdotação (AH/SD), ela frequentemente cobra seu preço como um castigo. Tem dias em que eu só queria ficar de boa, sem processar 1 bilhão de hipóteses sobre o efeito em cascata que uma única decisão arquitetural errada pode causar em um sistema complexo.

Mas, como não dá para desligar a mente, a gente transforma isso em artigo. Agora que vocês me conhecem um pouco melhor, vamos à lore.

Como ainda não inventaram um comando para dar um kill -9 nos meus próprios pensamentos, e meu cérebro não roda com uma árvore de supervisão para me reiniciar num estado saudável quando a ansiedade bate, o único jeito de não esgotar meus próprios recursos computacionais à toa é documentar esse caos. Então, peguem o café, ajeitem a postura e preparem-se: se eu vou perder noites de sono calculando o custo de um autovalor no espaço vetorial, vocês vão ter que sofrer refletindo sobre isso comigo. Prometo que, no final, a matemática perdoa e a conta fecha.

A Filosofia Oculta das Ferramentas

Para os olhos de quem não o conhece, o gradiente descendente é apenas um emaranhado de derivadas parciais e taxas de aprendizado. Mas, em sua essência mais pura, ele revela um conceito filosófico profundo: a busca humilde por um estado de menor atrito. É a matemática da adaptação contínua, provando que a aproximação da verdade (o mínimo local) não se dá por um salto de genialidade, mas pela capacidade de medir o próprio erro e ajustar a direção no passo seguinte.

Quando olhamos para a arquitetura de sistemas sob essa ótica, percebemos que nenhuma ferramenta é apenas técnica. Cada escolha arquitetural carrega uma visão de mundo. E ao projetar sistemas multiagentes, compreender essa visão é o que nos permite priorizar técnicas que maximizem a qualidade em detrimento da mera quantidade. Quando se estabelecem métricas claras e uma prática de entrega contínua, o verdadeiro potencial desses agentes em projetos complexos é desbloqueado.

A Geometria do Significado

Um vetor em um espaço multidimensional não é um mero array de números de ponto flutuante. Filosoficamente, é a tentativa de dar coordenadas espaciais à abstração humana. Ao traduzir contexto para álgebra, definimos que a semântica possui gravidade e proximidade. Multiplicar esses vetores em um sistema de agentes é navegar pela geometria das ideias.

Em seu nível mais fundamental, agentes operam como multiplicadores de vetores e é aqui que a álgebra linear nos ensina uma lição valiosa. A magnitude de um vetor é inútil se a direção estiver errada; tampouco importa a força do multiplicador (o autovalor) se o vetor base for nulo.

Trazendo para a engenharia: um desenvolvedor pode aplicar uma força imensa, mas, sem o alinhamento correto, apenas se afastará do sentido e do objetivo com mais rapidez. Em contrapartida, um processo sem base sólida (o vetor nulo) esgotará os recursos computacionais à toa, pois nenhum fator multiplicador consegue escalar o vazio.

A Resiliência do Isolamento

Quando modelamos sistemas baseados em múltiplos agentes ou atores independentes que se comunicam por troca de mensagens e não compartilham estado, não estamos apenas lidando com concorrência. Estamos adotando a filosofia de que o mundo real é assíncrono, distribuído e inerentemente caótico.

Aceitamos que falhas locais são inevitáveis e que a verdadeira robustez (a tolerância a falhas) não nasce da tentativa fútil de prever e interceptar tudo. Ela nasce de entidades autônomas que sabem cair, se recuperar e continuar operando sem derrubar o ecossistema inteiro.

O Rigor da Especificação e o Custo da Iteração

Aprofundando a analogia do gradiente descendente na orquestração desses agentes, temos o ciclo matemático de otimização: tentativa, cálculo do erro, ajuste da direção e melhoria iterativa. No entanto, aplicar esse fluxo de "corrige e melhora" na prática tem um custo operacional e computacional consideravelmente alto.

É por isso que a prática de projetar e documentar antes de codificar transcende a gerência de projetos. É a compreensão de que, em um universo de possibilidades matemáticas infinitas e agentes com alto poder de alavancagem, a entropia é o estado natural. Adotar uma verdadeira especificação é um ato de rebelião contra o caos, é definir a topologia do terreno antes de soltar o algoritmo para explorá-lo.

Sem uma especificação rigorosa e métricas predefinidas, tentar encontrar a solução ideal apenas iterando cegamente transforma a inteligência do sistema em um dreno de recursos. Sem isso, iterar é apenas se perder no espaço vetorial com extrema eficiência.

O Fator Multiplicador Humano

Ferramentas, algoritmos e linguagens são apenas a manifestação sintática dessas ideias. O verdadeiro trabalho da engenharia não está em escrever a expressão matemática ou o código de integração, mas em compreender a natureza do problema a ponto de escolher a filosofia certa para resolvê-lo.

Em suma, lidar com agentes é lidar com alavancagem extrema. Se você alavanca um processo caótico, você apenas obtém o caos mais rápido e com uma conta muito mais cara no final. A verdadeira maestria na engenharia de sistemas multiagentes não está em deixar os modelos descobrirem o caminho sozinhos, mas em fornecer o rigor matemático e arquitetural para que eles tenham um vetor sólido de onde partir.

No fim do dia, a qualidade do autovalor gerado pela IA sempre será limitada pela qualidade da direção definida pelo humano.

Bibliography — PON + Smart Brewery dev.to series (EN drafts)

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:28:41 +0000

Bibliography — PON + Smart Brewery dev.to series (EN drafts)

Normalized references used across docs/devto/en/. When publishing on dev.to, prefer stable URLs; verify DOIs and publisher pages periodically.

Paradigms and architecture

Author(s)	Year	Title	Where
Simão, J. M.; Borges, M. R.; Ebina, R.; Tacla, C. A.; Stadzisz, P. C.; Banaszewski, R. F.	2013	Notification Oriented Paradigm (NOP) and Imperative Paradigm: A Comparative Study	SCIRP / IJSEA — academic treatment of NOP (closely related to “notification-oriented” rule structuring; this repo uses PON as shorthand).
Cockburn, A.	2005	Hexagonal architecture (ports and adapters)	alistair.cockburn.us
Fowler, M.	2015	Ports and Adapters / Hexagonal architecture (summary)	martinfowler.com

Erlang, Elixir, OTP

Author(s)	Year	Title	Where
Armstrong, J.	2003	Making reliable distributed systems in the presence of software errors (PhD thesis)	erlang.org
Cesarini, F.; Thompson, S.	2016	Programming Erlang (2nd ed.)	Pragmatic Bookshelf — OTP design, processes, supervision.
Elixir documentation	—	`GenServer`, `Registry`, `Supervisor`, `Macro`, `@behaviour`	hexdocs.pm/elixir
Mix profiling tasks	—	`mix profile.cprof`, `eprof`, `fprof`, `tprof`	hexdocs.pm/mix/Mix.Tasks.Profile.Cprof.html and sibling task modules

Phoenix ecosystem

Author(s)	Year	Title	Where
Phoenix LiveView	—	Guides and API	hexdocs.pm/phoenix_live_view
Phoenix PubSub	—	API	hexdocs.pm/phoenix_pubsub

Data pipelines and observability

Author(s)	Year	Title	Where
Broadway	—	Documentation	hexdocs.pm/broadway
GenStage	—	Documentation	hexdocs.pm/gen_stage
Telemetry	—	`telemetry` for Erlang/Elixir	hexdocs.pm/telemetry
Timescale, Inc.	—	TimescaleDB documentation	docs.timescale.com

Analytics and BI

Author(s)	Year	Title	Where
Kimball, R.; Ross, M.	2013	The Data Warehouse Toolkit (3rd ed.) — dimensional modeling	Wiley — star schema, facts/dimensions.
Microsoft	—	Power BI REST APIs (push datasets, etc.)	Microsoft Learn — Power BI REST
PostgreSQL Global Development Group	—	`GRANT`, roles, row security	postgresql.org/docs

Digital twins and industrial context

Author(s)	Year	Title	Where
Grieves, M.	2014	Digital Twin: Manufacturing Excellence Through Virtual Factory Replication	Often cited white paper on digital-twin vocabulary (search publisher copy; ISBN/institutional PDFs vary).

Machine learning lifecycle

Author(s)	Year	Title	Where
Breck, E.; et al.	2017	The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction	research.google
Elixir Numerics	—	Axon, Scholar (Neural Network / traditional ML in Elixir)	hexdocs.pm/axon, hexdocs.pm/scholar

Queues, performance, back-pressure

Author(s)	Year	Title	Where
Little, J. D. C.	1961	A Proof for the Queuing Formula L = λW	Operations Research — foundation for Little’s Law (relation of queue length, arrival rate, wait); Wikipedia summary with citation to original.
Erlang docs	—	`:erlang.process_info/2` (mailbox size, etc.)	erlang.org/doc/man/erlang.html

This repository (deep dives in Portuguese or internal)

Topic	Path
Performance, profilers, env matrix	`docs/performance-dev.md` — EN series walkthrough: Part 11 on dev.to — Dev profiling… · repo draft
Memory pressure heuristics	`docs/memory-pressure-heuristics.md`
Message storm mitigation	PT: `docs/artigos/19_mitigacao_message_storm_pon_elixir_smart_brewery.md` — EN series: Part 10 on dev.to — When notifications explode… · repo draft
ML practical guide (PT)	`docs/artigos/27_guia_pratico_treino_ml_smart_brewery.md`
Power BI / realtime notes	`docs/power-bi-realtime.md`

Retrospective: lessons from building a reactive rules engine in Elixir

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:26:49 +0000

If this helped you, you can support the author with a coffee on dev.to.

Retrospective: lessons from building a reactive rules engine in Elixir

Part 12 of 12 — This post closes the arc that started with why the BEAM fits reactive rules and ends with how we measure them under load. Part 11 on dev.to — Dev profiling: CPU, memory, and what changed after optimizations · repo draft was about profilers and reproducible workloads; here I zoom out: integrations that paid off, costs we accepted, and what I would try next if I were green-fielding tomorrow.

This is not a substitute for the earlier technical posts—treat it as a map and a checklist for your own PON-style systems. Each part now ends with a References and further reading section; the consolidated list lives in Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.

What the twelve parts built

Stretch	Idea
1–2	Notifications as the organizing principle; Facts, Rules, and Premises as OTP processes and `Registry` topics.
3–4	Less boilerplate via `defrule` / `defpremissa`; ports and adapters so rules do not hard-code IO.
5–6	Smart Brewery as a serious lab; LiveView as the operator’s window with batching and streams.
7–8	Broadway / GenStage, TimescaleDB, star-schema BI and safe read-only roles.
9	ML export / import and `ml_predictions` without blocking the engine.
10–11	Part 10 on dev.to — message storms, dedup and fan-out coalescence; Part 11 on dev.to — CPU/memory profiling with `PipelineWorkload`.

Together they describe one opinionated path: reactive core, async edges, honest measurement.

What worked well

Process boundaries match mental boundaries. A Fato is a named mailbox with a value; a Regra subscribes and reacts. That maps cleanly to drawings on a whiteboard and to Elixir supervision.

Explicit message shapes. Consumers understand {:notificacao, name, value} and {:notificacoes_lote, map}—whether they live in tec0301_pon or in the Phoenix app. Ambiguity is expensive at scale.

Two applications, one story. Keeping tec0301_pon as the engine and simulacoes_visuais as warehouse + UI avoided turning the rule engine into an Ecto or HTTP library, while still shipping a full twin demo.

Batching at the pain points. LiveView batchers, Broadway batchers, Fanout.atualizar_lote/1, and async DB writers share the same philosophy: coalesce before fan-out or disk.

Telemetry as a spine, not an afterthought. From rule firings to Broadway flushes, the codebase repeatedly uses :telemetry.execute/3 and named events so you can correlate “the twin moved” with “the UI updated” and “rows landed in TimescaleDB.” That does not replace profilers, but it anchors them: when CPU spikes, you want a span or counter that says which stage grew.

Trade-offs we accepted

DSL complexity. Macros that generate rule modules are powerful and testable, but they are a onboarding cliff. Teams that fear metaprogramming will push for YAML or database rules—each has its own cost.

Simulation vs. fidelity vs. CPU. Monte Carlo noise, strict === deduplication, and float quantization are linked: quieter logs mean less work, but also less “physical” continuity unless you design for it.

Pragmatic coupling in examples. Rules that call Adapters.PredioIO directly are easy to read; “production-shaped” indirection via Application.get_env/3 is more wiring. The series kept both stories visible.

Operational surface. TimescaleDB, CAGGs, retention, Power BI roles, and ML export paths are optional but real: the default mix phx.server story is heavier than a pure library.

English drafts, Portuguese publication layer. Keeping docs/devto/en/*.md as the paste-ready source while devto_serie_pon_smart_brewery.md tracks PT titles and dev.to slugs adds a bit of bookkeeping. The upside is a single technical narrative in one language and localized packaging when you hit publish.

What I would try earlier next time

Profiling harness from week one — PipelineWorkload-style reproducible ticks save arguments about regressions.
One canonical env matrix — document SIMULACOES_TSDB_ENABLED, Monte Carlo interval, and Broadway batch sizes in a single table (the repo now spreads this across performance-dev.md and config; still easy to drift).
Stable join keys — align persisted rule_events.regra_id with dimension tables (r_01 vs "1") in one migration or view, so BI and ML exports do not need ad hoc bridges.
Stricter “no work if unchanged” policy — extend the dedup story to any hot path that allocates (e.g. telemetry encode) once profiling proves it matters.

These are hypotheses, not promises—verify on your workload.

Code spine (the same system, twelve lenses)

Part 2 / 10 — fact update and dispatch only when the value changes:

# lib/tec0301_pon/pon/fato.ex (concept)
def handle_cast({:atualizar, novo_valor}, estado) do
  if valor_igual?(estado.valor, novo_valor) do
    {:noreply, estado}
  else
    # … update state, ETS, Registry.dispatch → {:notificacao, nome, valor}
    {:noreply, novo_estado}
  end
end

Part 3 — DSL-shaped rule:

defrule RegraIrrigacao,
  watch: [:temp_ambiente, :umidade_solo, :estado_bomba, :nivel_tanque],
  when: memoria[:temp_ambiente] > 30 and memoria[:umidade_solo] < 40,
  do: (
    Adapters.BombaDeAgua.ligar()
    Tec0301Pon.PON.Fato.atualizar(:estado_bomba, :ligada)
  )

Part 4 — port = behaviour:

defmodule Tec0301Pon.Ports.PredioAtuadores do
  @callback ligar_luz() :: :ok
  @callback trancar_porta() :: :ok
end

Part 6 — operator route:

live "/smart-brewery", SmartBreweryLive, :index
live "/smart-brewery/ml-predictions", MlPredictionsLive, :index

Part 7 — Broadway flush to PubSub and optional TSDB:

if Application.get_env(:simulacoes_visuais, :tsdb_enabled, false) do
  SimulacoesVisuais.SmartBrewery.TelemetryAsyncWriter.cast_batch(list)
end

Part 9 — export and import (shell):

mix export.ml --out /tmp/ml_export --since-hours 168
mix import.ml.predictions --file /tmp/preds.jsonl

[Part 11 on dev.to](https://dev.to/matheuscamarques/dev-profiling-cpu-memory-and-what-changed-after-optimizations-28hb) — reproducible load:

mix profile.cprof -e "SimulacoesVisuais.Profile.PipelineWorkload.run()"

End-to-end picture

flowchart LR
  subgraph engine [tec0301_pon]
    F[Fato]
    R[Regra]
    A[Adapters]
  end
  subgraph app [simulacoes_visuais]
    MC[MonteCarlo]
    BW[Broadway]
    LV[LiveView]
    TSDB[(TimescaleDB)]
  end
  MC --> F
  F --> R
  R --> A
  F --> BW
  BW --> TSDB
  BW --> LV

Series index (parts 1–12 + consolidated bibliography)

Part	Title	Draft / published
1	Notification-Oriented Paradigm (PON) in Elixir: why the BEAM fits reactive rules	dev.to · repo draft
2	From whiteboard to code: mapping Facts, Rules, and Premises to OTP processes	dev.to · repo draft
3	A metaprogrammed DSL: `defrule` and `defpremissa` with less PON boilerplate	dev.to · repo draft
4	Hexagonal architecture + PON: Ports & Adapters to decouple the engine	dev.to · repo draft
5	Smart Brewery: a digital twin brewery as a PON lab	dev.to · repo draft
6	Phoenix LiveView in real time: an operations UI on top of a rules engine	dev.to · repo draft
7	From simulation to storage: telemetry, Broadway/GenStage, and TimescaleDB	dev.to · repo draft
8	BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI)	dev.to · repo draft
9	ML on the digital twin: export, train pilots, and import predictions back into the app	dev.to · repo draft
10	When notifications explode: message storms, deduplication, and back-pressure in PON	dev.to · repo draft
11	Dev profiling: CPU, memory, and what changed after optimizations	dev.to · repo draft
12	Retrospective: lessons from building a reactive rules engine in Elixir	this post
13	Bibliography — PON + Smart Brewery dev.to series (EN drafts)	dev.to · repo draft

Portuguese titles and publication notes for dev.to live in docs/devto_serie_pon_smart_brewery.md.

References and further reading (series-level)

Master bibliography — normalized table of books, papers, and docs used across Parts 1–12: Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.
NOP / PON — Simão et al. (2013) comparative study — SCIRP.
OTP / BEAM — Armstrong (2003) thesis — PDF; Cesarini & Thompson, Programming Erlang.
Hexagonal — Cockburn — ports and adapters.
Data + time-series — Kimball & Ross (dimensional modeling); TimescaleDB — docs.timescale.com.
ML readiness — Breck et al., ML Test Score — Google Research.

Thank you

If you followed from Part 1 on dev.to: you have seen one way to marry reactive rules, OTP, and industrial-style twins—not the only way. Take the patterns (boundaries, batching, measurement) and adapt the machinery to your domain.

End of series.

Previous: Part 11 on dev.to — Dev profiling: CPU, memory, and what changed after optimizations · repo draft

Code map (monorepo root): lib/tec0301_pon/, apps/simulacoes_visuais/, docs/performance-dev.md, docs/devto_serie_pon_smart_brewery.md.

Dev profiling: CPU, memory, and what changed after optimizations

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:22:45 +0000

If this helped you, you can support the author with a coffee on dev.to.

Dev profiling: CPU, memory, and what changed after optimizations

Part 11 of 12 — Part 10 on dev.to — When notifications explode: message storms, deduplication, and back-pressure in PON · repo draft described deduplication, fan-out batching, and mailbox draining in the PON core. Those changes are meant to reduce wasted work—but you only know they helped if you measure the same workload twice under the same knobs.

This post is a practical guide to dev profiling in this monorepo: reproducible load via SimulacoesVisuais.Profile.PipelineWorkload, Mix tasks built on OTP profilers, and how to read results without fooling yourself. Deep dives and longer checklists live in docs/performance-dev.md and docs/memory-pressure-heuristics.md. Part 12 closes the series with a retrospective.

What profilers actually show

On the BEAM, mix profile.cprof, eprof, fprof, and (OTP 27+) tprof answer different questions (official task docs under Mix.Tasks.Profile on HexDocs; flags and caveats in this repo are expanded in performance-dev.md):

Tool	Rough question
cprof	Which functions ran most often?
eprof	Where did this process spend time?
fprof	What does the call graph look like in time?
tprof	Aggregated time, calls, or allocation (WORDS) across processes

None of them is a direct “heap map.” RAM pressure still needs :erlang.memory/0, Process.info/2, Observer, or LiveDashboard VM metrics—hot code paths that allocate a lot often correlate with high call counts, but correlation is not identity.

Reproducible load: `PipelineWorkload`

The module SimulacoesVisuais.Profile.PipelineWorkload runs Monte Carlo ticks through the same stack as production-style simulation: PON facts, hybrid models, telemetry fan-out, and (if enabled) TSDB writers.

# SimulacoesVisuais.Profile.PipelineWorkload.run/1 (opening)
def run(opts \\ []) when is_list(opts) do
  duration_ms = Keyword.get(opts, :duration_ms) || env_duration_ms()
  ticks = Keyword.get(opts, :ticks, env_int("PROFILE_PIPELINE_TICKS", 30))
  max_ticks = Keyword.get(opts, :max_ticks, env_int("PROFILE_PIPELINE_MAX_TICKS", 5_000_000))
  mode = Keyword.get(opts, :mode, mode_from_env())
  memory? = Keyword.get(opts, :memory, env_bool("PROFILE_PIPELINE_MEMORY", false))

  {:ok, _} = Application.ensure_all_started(:simulacoes_visuais)
  MonteCarlo.stop_loop()
  if memory?, do: print_memory_section("before")
  # … duration_ms branch → run_until_deadline_* OR fixed tick count …
  if memory?, do: print_memory_section("after")
  :ok
end

Two modes matter for interpretation

:via_genserver (default) — calls SmartBreweryMonteCarlo.run_tick_sync/0. Realistic for end-to-end behavior; some profilers attribute time to the caller (e.g. Mix) as much as to the GenServer body.
:in_process — PROFILE_PIPELINE_MODE=in_process runs run_tick_pure/1 in the current process. Better for fprof-style call graphs; does not advance the live GenServer RNG state—profiling only.

Set duration instead of a fixed tick count with PROFILE_PIPELINE_DURATION_MS (milliseconds wall clock), capped by PROFILE_PIPELINE_MAX_TICKS.

Environment variables (cheat sheet)

Variable	Role
`PROFILE_PIPELINE_TICKS`	Fixed number of ticks when duration is off
`PROFILE_PIPELINE_DURATION_MS`	Run until wall-clock deadline
`PROFILE_PIPELINE_MAX_TICKS`	Safety ceiling for duration mode
`PROFILE_PIPELINE_MODE`	`via_genserver` (default) or `in_process`
`PROFILE_PIPELINE_MEMORY`	`1` / `true` → print `:erlang.memory/0` + key processes before/after
`SIMULACOES_TSDB_ENABLED`	Match your DB-on vs DB-off scenario
`LOGGER_LEVEL`	Often `warning` to reduce log noise during long runs

For before/after comparisons, also lock Monte Carlo and pipeline tuning: MONTE_CARLO_INTERVAL_MS, MONTE_CARLO_FACTS_PER_TICK_MIN / MAX, TELEMETRY_PIPELINE_BATCH_SIZE, TELEMETRY_PIPELINE_BATCH_TIMEOUT_MS, TELEMETRY_PRODUCER_MAX_QUEUE, OEE_PUBSUB_MIN_INTERVAL_MS—see the tables in performance-dev.md.

Quick commands

Call-count hotspot (cprof), TSDB off, long window:

cd apps/simulacoes_visuais
mkdir -p tmp/profile
PROFILE_PIPELINE_DURATION_MS=120000 LOGGER_LEVEL=warning \
  SIMULACOES_TSDB_ENABLED=false \
  mix profile.cprof -e "SimulacoesVisuais.Profile.PipelineWorkload.run()" \
  | tee tmp/profile/cprof-sample.txt

Narrow to one module:

mix profile.cprof --module SimulacoesVisuais.SmartBreweryMonteCarlo \
  -e "SimulacoesVisuais.Profile.PipelineWorkload.run()"

Memory snapshot without a profiler:

PROFILE_PIPELINE_MEMORY=1 PROFILE_PIPELINE_TICKS=30 \
  mix profile.pipeline
# alias for: mix simulacoes_visuais.profile_workload

OTP 27+ aggregated time:

PROFILE_PIPELINE_DURATION_MS=120000 LOGGER_LEVEL=warning \
  mix profile.tprof --type time --report total \
  -e "SimulacoesVisuais.Profile.PipelineWorkload.run()"

fprof trace file — put -e "..." before --trace-to-file, or Mix mis-parses the path:

mix profile.fprof -e "SimulacoesVisuais.Profile.PipelineWorkload.run()" \
  --trace-to-file tmp/profile/run.trace \
  | tee tmp/profile/fprof-out.txt

60-second battery

From the repo root, scripts/run_profile_60s.sh runs several profiler variants and writes under apps/simulacoes_visuais/tmp/profile/*-60s.txt. Useful when you want comparable artifacts after a change without hand-typing flags.

Profiling the Monte Carlo GenServer itself

With PipelineWorkload in default via_genserver mode, eprof attached to the Mix process often shows GenServer.call / client time—not the full body of SmartBreweryMonteCarlo. To attribute work to the right OTP process:

Start the app (mix phx.server or Application.ensure_all_started(:simulacoes_visuais)).
Resolve PIDs: Process.whereis(SimulacoesVisuais.SmartBreweryMonteCarlo), and when TSDB is on, writers such as RuleEventWriter.
Attach eprof / fprof to those PIDs from an iex session on the same node (see OTP profiling docs), while generating load from another shell or the UI.

Cross-check reductions and mailbox length in Observer or LiveDashboard while PROFILE_PIPELINE_MEMORY=1 prints heap and queue depth for the registered names the workload already tracks.

Baselines: “light” vs “heavy” server

Before blaming PON, confirm whether you are in a quiet or noisy dev profile. performance-dev.md suggests:

# Lighter: no TSDB, no auto Monte Carlo
PHX_LV_DEBUG=0 SIMULACOES_TSDB_ENABLED=false AUTO_START_MONTE_CARLO=false mix phx.server

# Heavier: TSDB, fast MC, more LiveView debug
PHX_LV_DEBUG=1 SIMULACOES_TSDB_ENABLED=true AUTO_START_MONTE_CARLO=true \
  MONTE_CARLO_INTERVAL_MS=500 mix phx.server

Profiling workloads should use the same economic assumptions as the hypothesis you are testing.

Optimizations this repo ties to measurements

Internal write-ups (Portuguese) connect architecture to numbers: article 18 (runtime), article 19 (message storm mitigation), article 20 (ETS write_concurrency, Registry partitions, Rete spike, Broadway tuning). The checklist at the top of performance-dev.md maps each item to modules—for example: Registry partitions in Tec0301Pon.Application, ETS read_concurrency / write_concurrency on fact values, Broadway :telemetry_pipeline_processor_concurrency / batcher settings in config, Fanout switching to Task.async_stream when the update map has more than four pairs, and optional Rete experiments via Tec0301Pon.PON.ReteSpike. Profiling tells you which row in that table actually matters for your tick rate and hardware.

Do not publish a single “we saved 40%” headline unless you have paired runs (same commit range, same env, same PROFILE_PIPELINE_*) and you document where the files live—otherwise you are storytelling, not benchmarking.

BI / TSDB sanity (one paragraph)

If charts look empty while telemetry_events has millions of rows, check time windows: mix verify.bi uses small LIMIT samples and often last 24h in SQL; mix verify.tsdb reports global counts and MAX(ts). Misaligned windows are a data issue, not a broken query—see performance-dev.md § BI native.

Flow under profiling

flowchart LR
  PW[PipelineWorkload]
  MC[SmartBreweryMonteCarlo]
  PON[PON Fato Regra]
  BW[Broadway Telemetry]
  W[AsyncWriters optional]
  Mix[Mix process profiler]
  PW --> MC
  MC --> PON
  PON --> BW
  BW --> W
  Mix -->|"via_genserver: often attributes client time"| MC
  Mix -->|"in_process: run_tick_pure only"| MC

Summary

Part 10 reduced redundant messages; Part 11 gives you the bench: PipelineWorkload, Mix profilers, memory snapshots, and explicit env discipline. Treat every optimization as a hypothesis until two traces agree. Part 12 zooms out with a series retrospective and a full index of posts.

References and further reading

Mix profiling — profile.cprof, profile.eprof, profile.fprof, profile.tprof — HexDocs (cprof) and sibling tasks.
Armstrong (2003) — process isolation and failure domains — thesis PDF (context for why mailbox/profiler stories matter).
In this repo — pipeline_workload.ex, performance-dev.md, memory-pressure-heuristics.md, run_profile_60s.sh; internal articles 18, 20. Expanded list: Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.

Published on dev.to: Dev profiling: CPU, memory, and what changed after optimizations — tracked in docs/devto_serie_pon_smart_brewery.md.

Previous: Part 10 on dev.to — When notifications explode: message storms, deduplication, and back-pressure in PON · repo draft

Next: Part 12 — Retrospective: lessons from building a reactive rules engine in Elixir — end of series (index + lessons learned).

When notifications explode: message storms, deduplication, and back-pressure in PON

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:18:07 +0000

If this helped you, you can support the author with a coffee on dev.to.

When notifications explode: message storms, deduplication, and back-pressure in PON

Part 10 of 12 — Part 9 on dev.to — ML on the digital twin: export, train pilots, and import predictions back into the app · repo draft showed how to export history and import model scores. Before adding more consumers, it pays to ask: what happens when the twin’s tick rate rises and every Fato.atualizar/2 fans out to many Regra processes?

This post is about message storms on the BEAM: redundant Registry.dispatch work, rule mailboxes full of duplicate context, and back-pressure at the edges. The patterns below are implemented in tec0301_pon and exercised by Smart Brewery + simulacoes_visuais. Deeper Portuguese notes live in docs/artigos/19_mitigacao_message_storm_pon_elixir_smart_brewery.md; reproducing profiles is covered in docs/performance-dev.md. Part 11 on dev.to zooms in on profiling methodology and before/after numbers. Intuitively, stable queueing systems obey Little’s Law (mean work in system ∝ arrival rate × mean delay—Little 1961); storms push the “work in system” term through the roof unless you cut redundant arrivals or widen the bottleneck.

Symptom: CPU spent orchestrating, not deciding

In actor-style PON graphs, one fact update can mean:

A GenServer cast on the fact process.
Registry.dispatch to every subscriber.
One message per rule that watches the fact.
Condition evaluation and possibly actions—again per message.

Under Monte Carlo or dense PLC simulation, steps 2–3 multiply into a storm: schedulers stay busy copying terms between processes, even when the business outcome would be the same after coalescing updates.

1. Deduplicate at the source (`Fato`)

If the new value is strictly equal to the current one (===), skip dispatch entirely and do not bump the fact’s notification statistics:

# lib/tec0301_pon/pon/fato.ex — handle_cast/2 (excerpt)
def handle_cast({:atualizar, novo_valor}, estado) do
  if valor_igual?(estado.valor, novo_valor) do
    {:noreply, estado}
  else
    novo_estado =
      estado
      |> Map.update(:estatisticas, 1, &(&1 + 1))
      |> Map.put(:valor, novo_valor)

    ets_put(estado.nome, novo_valor)

    Registry.dispatch(Tec0301Pon.PON.PubSub, estado.nome, fn inscritos ->
      for {pid, _} <- inscritos, do: send(pid, {:notificacao, estado.nome, novo_valor})
    end)

    {:noreply, novo_estado}
  end
end

Float note: equality is exact. Noisy floats should be quantized upstream (as in the Smart Brewery random walk) if you rely on this filter—adding a global epsilon for all types would surprise rules that compare structured terms.

2. Coalesce across facts (`Fanout` + `atualizar_lote/1`)

Correlated equipment often updates several facts in the same tick (e.g. filter pressure, clarity, pump speed). Calling atualizar/2 three times means three dispatches and three bursts to shared rules. Fato.atualizar_lote/1 applies {:atualizar_sem_dispatch, val} per changed fact, then sends one {:notificacoes_lote, map} per subscriber PID:

# lib/tec0301_pon/pon/fanout.ex — notify_lote/1 (excerpt)
defp notify_lote(changed) when is_map(changed) do
  pids =
    changed
    |> Map.keys()
    |> Enum.flat_map(fn key ->
      Registry.lookup(@pubsub, key) |> Enum.map(fn {pid, _} -> pid end)
    end)
    |> Enum.uniq()

  msg = {:notificacoes_lote, changed}
  Enum.each(pids, fn pid -> send(pid, msg) end)
end

Rules merge only the keys they watch:

# lib/tec0301_pon/pon/regra.ex — after {:notificacoes_lote, updates}
relevante = Map.take(updates, estado.fatos)
nova_memoria = Map.merge(estado.memoria, relevante)
{nova_memoria, drained} = drain_notificacoes(nova_memoria, estado, 0)
# then update :estatisticas_notificacoes and call avaliar_apos_memoria/2

Large batches use Task.async_stream with bounded concurrency inside Fanout.atualizar_lote/1; very small maps update sequentially—see the module for thresholds.

3. Drain the rule mailbox before evaluating (`drain_notificacoes/3`)

Even with fan-out reduced, bursts still happen. After applying the first notification, Regra empties the mailbox of more {:notificacao, …} / {:notificacoes_lote, …} with a zero-timeout receive, then runs one avaliar_condicao/2:

# lib/tec0301_pon/pon/regra.ex — drain (excerpt)
defp drain_notificacoes(memoria, estado, acc) do
  receive do
    {:notificacao, nome, valor} ->
      drain_notificacoes(Map.put(memoria, nome, valor), estado, acc + 1)

    {:notificacoes_lote, upd} when is_map(upd) ->
      rel = Map.take(upd, estado.fatos)
      drain_notificacoes(Map.merge(memoria, rel), estado, acc + 1)
  after
    0 ->
      {memoria, acc}
  end
end

This is debounce-by-draining: the rule sees the latest memory state for the burst window, not every intermediate message.

4. Fast reads without blocking the fact (`ETS`)

Hot paths that only need the current value (e.g. filling rule memory, Monte Carlo readers) call Fato.obter/1, which prefers a public ETS table with read_concurrency and write_concurrency:

# lib/tec0301_pon/pon/fato.ex — obter/1 (excerpt)
def obter(nome_do_fato) when is_atom(nome_do_fato) do
  case :ets.lookup(@ets_table, nome_do_fato) do
    [{^nome_do_fato, valor}] -> valor
    [] -> GenServer.call(nome_do_fato, :obter)
  end
end

Tec0301Pon.Application calls Fato.ensure_ets!() before registering the Registry so lookups are safe during startup races.

5. Back-pressure outside the engine (Phoenix / Broadway)

The PON core is not the only fan-out. SmartBreweryFactBroadcaster, LiveViewEventBatcher, TelemetryProducer (bounded queue with drop-oldest), and Broadway batchers implement pressure so PostgreSQL and LiveView do not amplify storms—see Part 6 on dev.to · repo draft and Part 7 on dev.to · repo draft. SmartBreweryMonteCarlo caches Application.get_env bounds in init so the tick loop does not hit the application environment on every iteration.

Message contract cheat sheet

Message	Typical producer	Consumer
`{:notificacao, name, value}`	`Fato` after a real change	Rules, telemetry bridge
`{:notificacoes_lote, %{atom => value}}`	`Fanout.notify_lote/1`	Same subscribers; rules `Map.take/2` relevant keys

Code that only ever calls atualizar/2 keeps the single-notification shape; simulation paths that batch use atualizar_lote/1.

Measuring (preview — full walkthrough in Part 11 on dev.to)

The repo ships SimulacoesVisuais.Profile.PipelineWorkload and Mix tasks such as mix profile.cprof for repeatable runs. Example harness (TSDB off, headless):

cd apps/simulacoes_visuais
mkdir -p tmp/profile
PROFILE_PIPELINE_DURATION_MS=60000 LOGGER_LEVEL=warning \
  SIMULACOES_TSDB_ENABLED=false SIMULACOES_HEADLESS=true \
  mix profile.cprof -e "SimulacoesVisuais.Profile.PipelineWorkload.run()" \
  | tee tmp/profile/cprof-sample.txt

Treat percent gains as hypotheses until you A/B the same workload on two commits; the internal article avoids advertising fixed “30–50%” without paired measurements.

Flow diagram

flowchart TB
  subgraph reduce [Reduce fan-out]
    F[Fato atualizar]
    D{Value changed?}
    FD[Registry dispatch]
    L[Fato atualizar_lote]
    FN[Fanout notify_lote]
  end
  subgraph rule [Rule process]
    M[Mailbox]
    DR[drain_notificacoes]
    EV[avaliar_condicao once]
  end
  F --> D
  D -->|no| X[no notify]
  D -->|yes| FD
  FD --> M
  L --> FN
  FN --> M
  M --> DR --> EV

Summary

Message storms are a property of graph fan-out, not a judgment on PON. This codebase mitigates them with deduplication, batch notifications, mailbox draining, ETS reads, and bounded telemetry pipelines—without changing what a rule means, only how often it is prodded. Part 11 on dev.to ties these knobs to profiles and memory heuristics.

References and further reading

Little, J. D. C. (1961) — A proof for the queuing formula L = λW — classic Little’s Law; Wikipedia entry with citation to Operations Research.
Erlang — :erlang.process_info/2 (mailbox length, etc.) — manual.
Elixir Registry — dispatch semantics — HexDocs.
In this repo — fato.ex, fanout.ex, regra.ex, application.ex; artigo 19, performance-dev.md. Expanded list: Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.

Published on dev.to: When notifications explode: message storms, deduplication, and back-pressure in PON — tracked in docs/devto_serie_pon_smart_brewery.md.

Previous: Part 9 on dev.to — ML on the digital twin: export, train pilots, and import predictions back into the app · repo draft

Next: Part 11 on dev.to — Dev profiling: CPU, memory, and what changed after optimizations · repo draft

ML on the digital twin: export, train pilots, and import predictions back into the app

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:13:39 +0000

If this helped you, you can support the author with a coffee on dev.to.

ML on the digital twin: export, train pilots, and import predictions back into the app

Part 9 of 12 — Part 8 on dev.to — BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI) · repo draft gave you a star-shaped analytical surface in PostgreSQL/TimescaleDB. Machine learning needs the same history in files or arrays, then a path to bring scores back where operators already look: the Phoenix app.

This post covers mix export.ml, the CSV contract documented in MLDatasetExport, in-Beam pilot trainers (mix simulacoes_visuais.ml_train), batch import of predictions as JSONL, and the /smart-brewery/ml-predictions LiveView. Part 10 on dev.to shifts to message storms and back-pressure in the PON engine.

For a longer Portuguese walkthrough (notebooks, Python sketches), see docs/artigos/27_guia_pratico_treino_ml_smart_brewery.md.

Closed loop in three hops

Export — Snapshot telemetry, OEE, anomalies, rule events, dimensions, and optional CAGG slices to a directory of CSVs.
Train / infer offline — Use Elixir pilots for demos, or Python/R/Julia on the same files; produce JSON Lines (one JSON object per row).
Import + display — mix import.ml.predictions (alias) bulk-inserts into ml_predictions; MlPredictionsLive lists recent rows.

Training itself is intentionally out of band: the app does not need GPU drivers to be valuable as the system of record for predictions. For production readiness checklists (monitoring, data validation, CI for models), Google’s ML Test Score rubric is a compact reference (Breck et al., 2017); this repo implements only a thin slice—export/import contracts and a LiveView reader—not full MLOps.

Step 1: `mix export.ml`

From apps/simulacoes_visuais, with :tsdb_enabled and migrations applied:

mix export.ml --out /tmp/ml_export --since-hours 168
# Long form: mix simulacoes_visuais.export_ml --out /tmp/ml_export --since-hours 72
# Skip some CAGGs if missing: --no-cagg or --no-cagg-1h-1day

The task delegates to SimulacoesVisuais.MLDatasetExport.export_all/2, which writes UTF-8 CSVs with headers. The module’s moduledoc is the contract for downstream notebooks—example excerpts:

# SimulacoesVisuais.MLDatasetExport @moduledoc (SQL shapes, excerpt)
# Telemetry (multivariate series)
#   SELECT ts, fact_name, value_float, value_int, value_str, ...
#   FROM telemetry_events WHERE ts >= $1 ORDER BY ts ASC;
# OEE (regression target)
#   SELECT ts, oee_pct, availability_pct, performance_pct, quality_pct, ...
#   FROM oee_snapshots WHERE ts >= $1 ORDER BY ts ASC;
# Rule firings (discrete events)
#   SELECT ts, regra_id, case_id, ... FROM rule_events WHERE ts >= $1 ...
# Dimensions + telemetry_events_1min / _1h / _1day — see source for full SQL.

Typical filenames include telemetry_events.csv, oee_snapshots.csv, rule_events.csv, dim_equipamento_fbe.csv, and CAGG exports—matching the README’s headless simulation story (Docker Postgres, Monte Carlo, then export).

The same migration that introduced ml_predictions also adds case_id to rule_events, so exported rule traces can align with process-mining style case identifiers when you join predictions back to operational event logs.

Step 2a: Elixir pilots (Scholar / Axon)

For reproducible demos without leaving the BEAM, mix simulacoes_visuais.ml_train reads the same CSV directory:

mix simulacoes_visuais.ml_train --dir /tmp/ml_export --pilot oee
mix simulacoes_visuais.ml_train --dir /tmp/ml_export --pilot fermentation --epochs 40
mix simulacoes_visuais.ml_train --dir /tmp/ml_export --pilot anomaly --epochs 40

oee — Scholar linear regression baseline on exported OEE series.
fermentation — Axon MLP pilot on fermentation-related signals.
anomaly — Axon autoencoder focused on FBE_01-style vibration features.

The task prints metrics to the shell; production workflows usually emit JSONL from a separate inference job and import below.

Step 2b: JSONL format for import

Each line is a JSON object. model_name is required; ts is optional (defaults to “now” in UTC, normalized to microsecond precision for Ecto).

{"model_name":"oee_linear_v1","ts":"2025-03-20T12:00:00.000000Z","target_name":"oee_pct","value_float":87.4,"metadata":{"rmse":2.1,"export_window_h":168}}

Optional fields: target_name, value_float, metadata (object, stored as JSON in Postgres).

Step 3: persist predictions — schema and context

The migration creates a narrow fact table for batch scores:

# priv/repo/migrations/20260319120000_add_rule_events_case_id_and_ml_predictions.exs (excerpt)
create table(:ml_predictions, primary_key: false) do
  add :id, :binary_id, primary_key: true
  add :ts, :utc_datetime_usec, null: false
  add :model_name, :string, null: false
  add :target_name, :string
  add :value_float, :float
  add :metadata, :map
  timestamps(type: :utc_datetime_usec)
end

create index(:ml_predictions, [:ts])
create index(:ml_predictions, [:model_name, :ts])

# SimulacoesVisuais.MlPrediction (schema excerpt)
@primary_key {:id, :binary_id, autogenerate: true}
schema "ml_predictions" do
  field(:ts, :utc_datetime_usec)
  field(:model_name, :string)
  field(:target_name, :string)
  field(:value_float, :float)
  field(:metadata, :map)
  timestamps(type: :utc_datetime_usec)
end

Bulk insert from decoded JSON maps:

# SimulacoesVisuais.MlPredictions.insert_from_decoded_maps/1 (excerpt)
# Each map must include "model_name"; missing model raises ArgumentError.
rows =
  Enum.map(maps, fn m ->
    m = Map.new(m, fn {k, v} -> {to_string(k), v} end)
    %{
      id: Ecto.UUID.generate(),
      ts: parse_ts(m["ts"]) || now,
      model_name: m["model_name"],
      target_name: m["target_name"],
      value_float: m["value_float"],
      metadata: m["metadata"] || %{},
      inserted_at: now,
      updated_at: now
    }
  end)

{n, _} = Repo.insert_all(MlPrediction, rows)
{:ok, n}

Mix task: import from disk

# mix simulacoes_visuais.ml_import_predictions @moduledoc (usage)
#   mix simulacoes_visuais.ml_import_predictions --file /path/to/preds.jsonl
# Alias in mix.exs: mix import.ml.predictions --file /path/to/preds.jsonl

The task streams the file, Jason.decode!/1 per line, and calls MlPredictions.insert_from_decoded_maps/1. It requires :tsdb_enabled so Repo is part of the running app configuration you expect in TSDB workflows.

LiveView: `/smart-brewery/ml-predictions`

# SimulacoesVisuaisWeb.MlPredictionsLive — mount/3 (excerpt)
def mount(_params, _session, socket) do
  {preds, tsdb?} = load_predictions()
  {:ok, assign(socket, predictions: preds, tsdb_enabled: tsdb?)}
end

defp load_predictions do
  tsdb? = Application.get_env(:simulacoes_visuais, :tsdb_enabled, false)

  preds =
    if tsdb? do
      SimulacoesVisuais.MlPredictions.list_recent(100)
    else
      []
    end

  {preds, tsdb?}
end

Router (already introduced in Part 6 on dev.to):

live "/smart-brewery/ml-predictions", MlPredictionsLive, :index

The template surfaces timestamp, model, target, and value, plus a Refresh button—enough to validate that your batch job actually landed in the warehouse.

Flow diagram

flowchart LR
  subgraph db [TimescaleDB]
    TE[telemetry_events]
    OEE[oee_snapshots]
    RE[rule_events]
    DIM[dimensions]
    MP[ml_predictions]
  end
  subgraph offline [Offline ML]
    CSV[CSV export dir]
    PY[Python / R / etc.]
    JSONL[preds.jsonl]
  end
  subgraph beam [Elixir optional]
    PILOT[ml_train pilots]
  end
  TE --> Export
  OEE --> Export
  RE --> Export
  DIM --> Export
  Export[mix export.ml] --> CSV
  CSV --> PY
  CSV --> PILOT
  PY --> JSONL
  Import[mix import.ml.predictions] --> MP
  JSONL --> Import
  MP --> LV[MlPredictionsLive]

Summary

Part 7 on dev.to and Part 8 on dev.to built and modeled historical plant data. This post completes the ML ergonomics: standard CSV exports, documented SQL, optional BEAM-native pilots, a simple import contract, and a LiveView to read ml_predictions. Next: keeping the notification graph healthy when rates spike (Part 10 on dev.to).

References and further reading

Breck et al. (2017) — The ML Test Score — Google Research (production-readiness rubric; not a tutorial).
Axon / Scholar — neural and classical ML in Elixir — hexdocs.pm/axon, hexdocs.pm/scholar.
In this repo (PT) — docs/artigos/27_guia_pratico_treino_ml_smart_brewery.md.
In this repo (code) — export_ml task, ml_dataset_export.ex, ml_train task, ml_import_predictions task, ml_predictions.ex, ml_predictions_live.ex. Expanded list: Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.

Published on dev.to: ML on the digital twin: export, train pilots, and import predictions back into the app — tracked in docs/devto_serie_pon_smart_brewery.md.

Previous: Part 8 on dev.to — BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI) · repo draft

Next: Part 10 on dev.to — When notifications explode: message storms, deduplication, and back-pressure in PON · repo draft

BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI)

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:09:28 +0000

If this helped you, you can support the author with a coffee on dev.to.

BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI)

Part 8 of 12 — Part 7 on dev.to — From simulation to storage: telemetry, Broadway/GenStage, and TimescaleDB · repo draft landed raw rows in telemetry_events and sibling tables for OEE, anomalies, and rule firings. Analysts rarely want fifty-seven wide columns per millisecond; they want a model they can relate in a semantic layer and refresh on a schedule—or query live with guardrails.

This post describes the star-style objects in the Smart Brewery Postgres/Timescale database, how SimulacoesVisuais.SmartBreweryBI mirrors those queries for the in-app BI tab, and how Power BI (or any SQL BI tool) can connect safely. Part 9 on dev.to picks up ML exports and prediction round-trips. The dimensional vocabulary—facts vs dimensions, conformed keys, slowly changing attributes—follows the Kimball-style methodology (The Data Warehouse Toolkit, 3rd ed., Wiley); our schema is a pragmatic subset for a twin demo, not a full enterprise bus matrix.

Why not query only `telemetry_events`?

The hypertable is the source of truth for high-volume numeric telemetry. For dashboards you usually:

Bucket time with time_bucket (TimescaleDB).
Aggregate (avg, min, max) per bucket and signal.
Join to dimensions so charts show “Fermentador A” instead of fbe_06_internal_temp.

Continuous aggregates (telemetry_events_1min, _1h, _1day) precompute that roll-up. Views on top expose a fact shape with fbe_id and fact_name ready for foreign-key-style relationships in Power BI.

Dimension tables: equipment and variables

The migration seeds two conformed dimensions used across reports:

# priv/repo/migrations/20250319200000_add_star_schema_dimensions_and_fact_views.exs (excerpt)
create table(:dim_equipamento_fbe, primary_key: false) do
  add :fbe_id, :string, primary_key: true
  add :nome, :string, null: false
  add :fase_operacional, :string
end

# INSERT … FBE_01 … FBE_11 with Portuguese operational labels

create table(:dim_variaveis_mapeamento, primary_key: false) do
  add :fact_name, :string, primary_key: true
  add :descricao, :string, null: false
  add :unidade, :string
end

# INSERT … maps each fbe_XX_* fact atom string to human description + unit

A later migration adds descricao_longa (aligned with FatoDescriptions) and dim_regras: metadata for PON rules (r_01 … r_12) so rule_events can be explained in plain language—see 20260320140000_power_bi_dim_context.exs.

Calendar dimension and fact views

dim_calendario is built from distinct buckets of the 1-minute continuous aggregate—useful for time-intelligence style filters without scanning the full hypertable:

-- From the same migration (conceptual shape)
CREATE VIEW dim_calendario AS
SELECT DISTINCT
  bucket AS ts_bucket,
  date_trunc('day', bucket)::timestamptz AS dt,
  EXTRACT(YEAR FROM bucket)::int AS year,
  EXTRACT(MONTH FROM bucket)::int AS month,
  ...
FROM telemetry_events_1min;

Fact views project CAGG columns into a stable star join key:

CREATE VIEW fact_telemetria_agregada_1min AS
SELECT bucket AS ts_bucket,
  UPPER(SUBSTRING(fact_name FROM 1 FOR 7)) AS fbe_id,
  fact_name,
  value_float_avg AS avg_value,
  value_float_min AS min_value,
  value_float_max AS max_value
FROM telemetry_events_1min;

Parallel views exist for _1h and _1day grains. In Power BI, typical relationships are: fact → dim_equipamento_fbe on fbe_id, fact → dim_variaveis_mapeamento on fact_name, fact → dim_calendario on ts_bucket.

CAGG latency vs freshness: Continuous aggregates refresh on a policy schedule (see migrations under priv/repo/migrations for telemetry_events_1min and friends). That is ideal for import or DirectQuery models that scan fewer rows per question. When operators need charts that track the last minutes without waiting for the next rollup refresh, SmartBreweryBI hits telemetry_events directly with time_bucket—same SQL idioms, different freshness/cost trade-off.

Practical note: rule_events.regra_id is persisted as the string form of the numeric rule id (e.g. "1"). dim_regras uses keys like "r_01". For joins you may add a calculated column or a small bridge in SQL—worth standardizing in one place for your deployment.

Offline analytics: mix export.ml (with TSDB enabled) emits CSV slices of telemetry, OEE, anomalies, rules, and dimension tables—useful for Python/R notebooks or training pipelines before Part 9 on dev.to’s prediction import path.

Event facts beside telemetry

Telemetry is only one analytical slice. The same database holds oee_snapshots (availability / performance / quality components over time), anomaly_events (EMA-driven highlights aligned with the operator UI), and rule_events (which PON rule fired, with optional case_id for scenario tracking). None of these replace the star views—they complement them: a single Power BI report can place OEE line charts next to aggregated temperature trends and a table of recent rule firings, all filtered by the same time slicer on ts.

Native BI in Elixir: `SmartBreweryBI`

The Phoenix app does not require Power BI for demos. SmartBreweryBI centralizes parameterized SQL: OEE cards, telemetry trends with time_bucket, correlation pivots, synoptic averages by FBE, anomaly Pareto, and rule counts.

# SimulacoesVisuais.SmartBreweryBI (excerpt)
def default_filters do
  %{
    "window" => "24h",
    "granularity" => "1h",
    "fbe_id" => "all",
    "fact_name" => "all"
  }
end

def dashboard_data(filters) do
  filters = normalize_filters(filters)
  hours = window_to_hours(filters["window"])

  %{
    oee_cards: oee_cards(hours),
    oee_trend: oee_trend(hours, filters["granularity"]),
    telemetry_trend: telemetry_trend(filters, hours),
    cep_chart: cep_chart(filters, hours),
    correlation_points: correlation_points(filters, hours),
    synoptic_status: synoptic_status(hours),
    anomaly_pareto: anomaly_pareto(hours),
    rule_top: rule_top(hours),
    totals: totals(hours)
  }
end

The BI view mode in SmartBreweryLive (Part 6 on dev.to) loads this map when :tsdb_enabled is true—same warehouse, two consumers (LiveView vs external BI).

For near-real-time trends, the module prefers querying telemetry_events with time_bucket for selected panels so results are not delayed by CAGG refresh policies; aggregated views remain the sweet spot for heavier report workloads.

Governance: read-only database role

The migration AddPowerbiAnalyticsReadonlyRole creates powerbi_analytics: LOGIN, CONNECT to the database, USAGE on public, SELECT on tables and default privileges for future tables. The BI connector should not use the application superuser.

# Excerpt from 20250319400000_add_powerbi_analytics_readonly_role.exs
execute format('CREATE ROLE powerbi_analytics WITH LOGIN PASSWORD %L', '#{escaped}')
execute "GRANT USAGE ON SCHEMA public TO powerbi_analytics;"
execute "GRANT SELECT ON ALL TABLES IN SCHEMA public TO powerbi_analytics;"
execute "ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO powerbi_analytics;"

Set POWERBI_ANALYTICS_PASSWORD before migrating in real environments.

Optional: push rows to Power BI REST

When Import/DirectQuery is not enough for a “live tile” experiment, PowerBIPushSink can enqueue rows after they are persisted, throttle HTTP calls, and POST to the Push datasets API. It is off by default (:power_bi_push → enabled: false).

# SimulacoesVisuais.SmartBrewery.PowerBIPushSink — encode_row/2 (excerpt)
defp encode_row(%{ts: ts, fact_name: fact_name, value_float: vf, value_int: vi, value_str: vs}, opts) do
  fact_str = to_string(fact_name)

  base = %{
    "ts" => datetime_to_iso8601(ts),
    "fact_name" => fact_str,
    "value_float" => vf,
    "value_int" => vi,
    "value_str" => vs
  }

  if Keyword.get(opts, :include_labels, true) do
    desc = SimulacoesVisuais.SmartBrewery.FatoDescriptions.descricao_bin(fact_str)
    Map.put(base, "descricao", desc)
  else
    base
  end
end

Operational guidance (latency vs license, DirectQuery vs push) lives in docs/power-bi-realtime.md at the repo root.

Verify the model: `mix verify.bi`

The Mix task runs SmartBreweryBI.run_query_diagnostics/0: each diagnostic query returns :ok with a small LIMIT sample, or an error you can fix before publishing reports.

# From apps/simulacoes_visuais (TSDB enabled)
mix verify.bi
# alias: mix simulacoes_visuais.verify_bi_queries

Zero rows in a sample is still success if your simulation was off—the README stresses distinguishing “query broken” from “empty time window”.

Architecture sketch

flowchart LR
  subgraph warehouse [Postgres / TimescaleDB]
    TE[telemetry_events]
    CAGG[telemetry_events_1min / 1h / 1day]
    F1[fact_telemetria_agregada_*]
    D1[dim_equipamento_fbe]
    D2[dim_variaveis_mapeamento]
    DC[dim_calendario]
    DR[dim_regras]
    OEE[oee_snapshots]
    RE[rule_events]
  end
  subgraph consumers [Consumers]
    LV[SmartBrewery BI tab]
    PBI[Power BI DirectQuery / Import]
    PUSH[Power BI Push optional]
  end
  TE --> CAGG
  CAGG --> F1
  F1 --> D1
  F1 --> D2
  F1 --> DC
  RE --> DR
  LV --> SmartBreweryBI
  SmartBreweryBI --> TE
  SmartBreweryBI --> OEE
  PBI --> F1
  PBI --> D1
  TE --> PUSH

Summary

Part 7 on dev.to wrote fast facts; this post makes them legible: conformed dimensions, CAGG-backed fact views, a read-only role, optional push, and a single Elixir module that encodes the same SQL the UI and mix verify.bi rely on. Next, we close the loop with ML on top of these exports (Part 9 on dev.to).

References and further reading

Kimball, R.; Ross, M. — The Data Warehouse Toolkit (3rd ed.) — dimensional modeling, star schema, fact/grain discipline (Wiley).
TimescaleDB — continuous aggregates as rollups — docs.timescale.com.
Microsoft Learn — Power BI REST / push datasets (see also in-repo power-bi-realtime.md).
PostgreSQL — roles, GRANT, least privilege — documentation.
In this repo — smart_brewery_bi.ex, power_bi_push_sink.ex, migrations 20250319200000_add_star_schema_dimensions_and_fact_views.exs, 20250319400000_add_powerbi_analytics_readonly_role.exs. Expanded list: Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.

Published on dev.to: BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI) — tracked in docs/devto_serie_pon_smart_brewery.md.

Previous: Part 7 on dev.to — From simulation to storage: telemetry, Broadway/GenStage, and TimescaleDB · repo draft

Next: Part 9 on dev.to — ML on the digital twin: export, train pilots, and import predictions back into the app · repo draft

From simulation to storage: telemetry, Broadway/GenStage, and TimescaleDB

Matheus de Camargo Marques — Fri, 20 Mar 2026 17:06:08 +0000

If this helped you, you can support the author with a coffee on dev.to.

From simulation to storage: telemetry, Broadway/GenStage, and TimescaleDB

Part 7 of 12 — Part 6 on dev.to — Phoenix LiveView in real time: an operations UI on top of a rules engine · repo draft showed how LiveView stays responsive: batched PubSub messages and a second throttle before touching assigns. This post goes one layer deeper: what happens when those same Fato.atualizar/2 notifications must also become durable rows in PostgreSQL with the TimescaleDB extension—without blocking the rule processes or the UI.

We focus on the simulacoes_visuais Phoenix app: a GenStage producer, a Broadway pipeline with configurable batching, an asynchronous GenServer writer, and hypertables with retention. Dimensional BI and Power BI consumption are the subject of Part 8 on dev.to.

Why a separate persistence path?

The PON engine (tec0301_pon) is optimized for reactive evaluation: Registry, Fato processes, and rule notifications. Long-running Repo.insert_all/3 calls do not belong on that hot path. The Phoenix application therefore acts as a sink, using the same back-pressure vocabulary as GenStage (demand-driven stages) and Broadway (batched consumers)—see the GenStage and Broadway documentation:

Subscribe to the engine’s notification bus (via SmartBreweryFactBroadcaster).
Shape traffic with back-pressure-friendly stages (GenStage + Broadway, with a GenServer fallback batcher).
Publish merged batches to PubSub for subscribers (EMA, OEE, downstream services).
Persist only when :tsdb_enabled is true, through a queued async writer so database latency does not stall the pipeline.

Running mix run examples/smart_brewery_simulacao.exs at the monorepo root still exercises only :tec0301_pon; it does not fill telemetry_events. Only this app, with TSDB enabled, owns the warehouse path—see apps/simulacoes_visuais/README.md.

Turning the warehouse on: supervision and environment

At startup, SimulacoesVisuais.Application reads SIMULACOES_TSDB_ENABLED from the OS environment (falling back to Application.get_env(:simulacoes_visuais, :tsdb_enabled, false)). When enabled, it starts Repo plus dedicated writers before the HTTP endpoint:

# apps/simulacoes_visuais/lib/simulacoes_visuais/application.ex (excerpt)
tsdb_children =
  if tsdb_enabled do
    [
      SimulacoesVisuais.Repo,
      SimulacoesVisuais.SmartBrewery.TelemetryAsyncWriter,
      SimulacoesVisuais.SmartBrewery.OeeSnapshotWriter,
      SimulacoesVisuais.SmartBrewery.AnomalyEventWriter,
      SimulacoesVisuais.SmartBrewery.RuleEventWriter
    ]
  else
    []
  end

children =
  [
    # … PubSub, bridge, TelemetryPipeline, batchers, Monte Carlo, …
    tsdb_children,
    SimulacoesVisuaisWeb.Endpoint
  ]
  |> List.flatten()

Fact telemetry flows through TelemetryPipeline (always started) and reaches TelemetryAsyncWriter only when the flag is on. OEE, anomalies, and rule firings use separate PubSub topics and writers that also depend on Repo.

Convenience in dev: mix dev.tsdb / iex -S mix dev.tsdb aligns with the README so Postgres/TimescaleDB and Monte Carlo can run together for local demos.

GenStage producer: demand-driven ingest

SmartBreweryFactBroadcaster resolves the Broadway producer and sends GenStage.cast(producer_pid, {:event, nome_fato, novo_valor}). The producer keeps a bounded queue; when the queue is full, the oldest event is dropped—trading completeness for bounded memory under burst load.

Critically, when Broadway has already requested demand with an empty queue, handle_cast/2 drains immediately so events are not stuck until the next handle_demand:

# SimulacoesVisuais.SmartBrewery.TelemetryProducer (excerpt)
def handle_cast(
      {:event, nome_fato, valor},
      %{queue: queue, max_queue: max_queue, pending_demand: pending} = state
    ) do
  new_queue =
    if :queue.len(queue) >= max_queue do
      {{:value, _dropped}, tail} = :queue.out(queue)
      :queue.in({nome_fato, valor}, tail)
    else
      :queue.in({nome_fato, valor}, queue)
    end

  if pending > 0 do
    {events, drained_queue} = take_from_queue(new_queue, pending)
    new_pending = pending - length(events)
    {:noreply, events, %{state | queue: drained_queue, pending_demand: new_pending}}
  else
    {:noreply, [], %{state | queue: new_queue}}
  end
end

If the producer PID cannot be resolved, the broadcaster falls back to SmartBreweryTelemetryBatcher; that path must still call TelemetryAsyncWriter.cast_batch/1 on flush so TSDB does not go silent while PubSub keeps working—a parity fix called out in the batcher’s moduledoc.

Broadway: processors, batchers, and one merged batch

TelemetryPipeline uses Broadway’s batcher stage to merge many {fact, value} messages into a single map per batch (last write wins per key), then fan-out:

# SimulacoesVisuais.SmartBrewery.TelemetryPipeline (excerpt)
Broadway.start_link(__MODULE__,
  name: __MODULE__,
  producer: [
    module: {TelemetryProducer, [name: :smart_brewery_telemetry_producer]},
    transformer: {__MODULE__, :transform, []}
  ],
  processors: [default: [concurrency: processor_concurrency]],
  batchers: [
    default: [
      concurrency: batcher_concurrency,
      batch_size: batch_size,
      batch_timeout: batch_timeout
    ]
  ]
)

def handle_batch(:default, messages, _batch_info, _context) do
  if messages != [] do
    merged = messages |> merge_message_data(%{})
    list = Map.to_list(merged)

    :telemetry.execute(
      [:simulacoes_visuais, :smart_brewery_telemetry_batcher, :flush],
      %{updates_count: length(list), buffer_size_before: length(list)},
      %{}
    )

    Phoenix.PubSub.broadcast(SimulacoesVisuais.PubSub, "smart_brewery:fatos", {:batch, list})
    push_ema_numeric_loop(list)

    if Application.get_env(:simulacoes_visuais, :tsdb_enabled, false) do
      SimulacoesVisuais.SmartBrewery.TelemetryAsyncWriter.cast_batch(list)
    end
  end

  messages
end

So each batch: metrics (LiveDashboard can chart flush sizes), PubSub on smart_brewery:fatos, EMA updates for anomaly heuristics, and optionally async persist. Part 6 on dev.to’s LiveView listens on a different topic (smart_brewery:liveview_batch) fed by LiveViewEventBatcher—same simulation, two consumption speeds.

TelemetryAsyncWriter: decouple DB latency from Broadway

cast_batch/1 enqueues whole batches; a bounded queue drops the oldest batch when overloaded, keeping recent telemetry:

# SimulacoesVisuais.SmartBrewery.TelemetryAsyncWriter (excerpt)
def cast_batch(list) when is_list(list) do
  GenServer.cast(__MODULE__, {:batch, list})
end

def handle_info(:flush, %{queue: [batch | rest]} = state) do
  persist(batch)
  Process.send_after(self(), :flush, 0)
  {:noreply, %{state | queue: rest}}
end

defp persist(list) do
  rows = SimulacoesVisuais.TelemetryEvent.changesets_from_batch(list)

  if rows != [] do
    SimulacoesVisuais.Repo.insert_all(SimulacoesVisuais.TelemetryEvent, rows)
    SimulacoesVisuais.SmartBrewery.PowerBIPushSink.cast_rows(rows)
  end
end

Broadway never waits on PostgreSQL; the writer serializes inserts and can hook optional push sinks for external analytics.

Row shape: from Elixir values to columns

TelemetryEvent.changesets_from_batch/2 maps {atom_name, value} tuples into flat maps suitable for insert_all/3—numbers as value_float, booleans split across value_int / value_str, other atoms as strings—so continuous aggregates and ML exports can choose the column that fits.

# SimulacoesVisuais.TelemetryEvent (excerpt)
defp to_row(nome, valor, now) when is_number(valor) do
  %{
    ts: now,
    fact_name: Atom.to_string(nome),
    value_float: to_float(valor),
    value_int: nil,
    value_str: nil,
    inserted_at: now,
    updated_at: now
  }
end

Rule events: same bus, different writer

Rule firings are published to smart_brewery:regras (for LiveView and others). RuleEventWriter subscribes, buffers up to a max pending count, and insert_all into rule_events in chunks—again isolating database work from the rule processes.

# SimulacoesVisuais.SmartBrewery.RuleEventWriter (excerpt)
def handle_info({:regra, regra_id}, state) do
  pending = state.pending ++ [{:regra, regra_id}]
  # … trim to max_pending …
  Process.send_after(self(), :drain, 0)
  {:noreply, %{state | pending: pending, draining: true}}
end

OEE snapshots and anomaly rows follow the same pattern (dedicated modules in SmartBrewery.*).

TimescaleDB: hypertable and retention

The initial migration enables the extension, creates telemetry_events, and promotes the table to a hypertable partitioned on ts, with a 7-day retention policy on raw rows (adjustable in your deployment):

# priv/repo/migrations/20250318000000_create_telemetry_events.exs (excerpt)
execute "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;", ""

create table(:telemetry_events, primary_key: false) do
  add :ts, :utc_datetime_usec, null: false
  add :fact_name, :string, null: false
  add :value_float, :float
  add :value_int, :integer
  add :value_str, :string
  timestamps(type: :utc_datetime_usec)
end

execute "SELECT create_hypertable('telemetry_events', 'ts', if_not_exists => true);", ""
execute "SELECT add_retention_policy('telemetry_events', INTERVAL '7 days');", ""

Later migrations add continuous aggregates (for example telemetry_events_1min, hourly and daily rollups) and compression policies on the hypertable. Those objects sit entirely in the database: the Elixir app keeps writing raw telemetry_events rows; BI queries and mix export.ml can target either the base table or the CAGGs depending on grain and export flags (--no-cagg, --no-cagg-1h-1day in the Mix task help).

Fallback batcher and TSDB parity

When the Broadway producer is unavailable, SmartBreweryTelemetryBatcher still merges updates and broadcasts {:batch, list} to smart_brewery:fatos. The flush handler mirrors the pipeline’s TSDB branch:

if Application.get_env(:simulacoes_visuais, :tsdb_enabled, false) do
  SimulacoesVisuais.SmartBrewery.TelemetryAsyncWriter.cast_batch(list)
end

Without this, operators would still see PubSub-driven UI signals while telemetry_events stayed flat—a classic split-brain symptom when debugging ingest.

End-to-end picture

flowchart TB
  subgraph engine [tec0301_pon]
    F[Fato]
  end
  subgraph ingest [simulacoes_visuais ingest]
    FB[SmartBreweryFactBroadcaster]
    P[TelemetryProducer GenStage]
    BW[TelemetryPipeline Broadway]
  end
  subgraph fanout [Fan-out]
    PS[PubSub smart_brewery:fatos]
    EMA[EMA / OEE inputs]
    W[TelemetryAsyncWriter]
  end
  subgraph db [PostgreSQL + TimescaleDB]
    T[(telemetry_events hypertable)]
    R[(rule_events etc.)]
  end
  F --> FB
  FB -->|GenStage.cast| P
  P --> BW
  BW --> PS
  BW --> EMA
  BW -->|cast_batch when tsdb_enabled| W
  W --> T
  RN[RegraNotifier] -->|PubSub regras| RW[RuleEventWriter]
  RW --> R

Operating and verifying

mix verify.tsdb — checks extension, row counts, recent timestamps, and whether the Broadway producer and writers are alive.
Headless simulation — SIMULACOES_TSDB_ENABLED=true AUTO_START_MONTE_CARLO=true mix phx.server (from the app directory) populates tables for ML export without opening the browser.
Retention — mix simulacoes_visuais.retention --days N (from the apps/simulacoes_visuais directory, TSDB enabled) replaces the hypertable retention policy without editing migrations—the default migration still installs a 7-day window.

Summary

Part 6 on dev.to optimized perception (UI). This post optimizes durability: GenStage demand, Broadway batching, bounded queues, async insert_all, and a time-series physical model. The engine stays reactive; the warehouse absorbs load on its own terms.

References and further reading

Broadway — batching, processors — hexdocs.pm/broadway.
GenStage — producers/consumers, demand — hexdocs.pm/gen_stage.
TimescaleDB — hypertables, continuous aggregates, retention — docs.timescale.com.
Telemetry — telemetry events in BEAM apps — hexdocs.pm/telemetry.
In this repo — application.ex, telemetry_pipeline.ex, telemetry_producer.ex, telemetry_async_writer.ex, smart_brewery_telemetry_batcher.ex, migration 20250318000000_create_telemetry_events.exs; docs/performance-dev.md. Expanded list: Bibliography on dev.to — PON + Smart Brewery series (EN drafts) · repo draft.

Published on dev.to: From simulation to storage: telemetry, Broadway/GenStage, and TimescaleDB — tracked in docs/devto_serie_pon_smart_brewery.md.

Previous: Part 6 on dev.to — Phoenix LiveView in real time: an operations UI on top of a rules engine · repo draft

Next: Part 8 on dev.to — BI without mystery: dimensions, facts, and consuming the data (e.g. Power BI) · repo draft

DEV Community: Matheus de Camargo Marques

PON-BEAM: um paradigma orientado a notificações dentro da máquina virtual do Erlang

PON-BEAM: um paradigma orientado a notificações dentro da máquina virtual do Erlang

1. A pergunta que move este projeto

2. O paradigma PON em 5 minutos

3. A fundação: um overlay compilável sobre o OTP

A telemetria da prova: pon_stats.h

4. Componente #1 — PON-Receive (Fase 1): Premises na mailbox

O problema: O(N × M)

A solução: Premises

Resultado medido

5. Componente #2 — PON-Timer (Fase 2): Instigações com timerfd

O problema: o timer wheel nunca dorme

A solução: Instigações temporais com o kernel

Resultado medido

6. Componente #3 — PON-Spawn (Fase 3): notificação no agendamento

O problema

A solução

Resultado medido

7. Componente #4 — PON-Scheduler (Fase 4): Conditions com eventfd + epoll

O problema: o busy-spin ocioso

A solução: a Condition

Resultado medido

8. Componente #5 — PON-ETS (Fase 5): side-table de watchers

O problema

A solução: watchers desacoplados

Resultado medido

9. Componente #6 — PON-Compiler (Fase 6): o receive vira Premise

O problema

A solução: parse transform para Premises

Resultado

10. Componente #7 — PON-GC (Fase 7): coleta tri-color por notificação (Dijkstra)

O problema

A solução: marcação por notificação

Resultado medido

11. Visão consolidada: onde cada entidade PON vive

12. Verificação formal: as 4 pilastras

13. Como reproduzir você mesmo

14. Conclusão

Referências

I Re-Architected the Erlang VM Core in C to Eliminate O(N) Loops — The PON-BEAM Saga

The Fundamental Flaw: The Cost of Polling

The Solution: The Notification-Oriented Paradigm

The Golden Rule: Surgical Isolation

The 7 Structural Victories

Formal Verification Pipeline

Conclusion

Modelo de Atores da BEAM vs. Scheduler Agent Supervisor: Mera Coincidência? O que a Ericsson com Erlang já resolveu no passado?

1. O Paradoxo da Nuvem Moderna: A Reinvenção da Roda Distribuída

2. Fundamentos Teóricos: De Carl Hewitt à Ericsson de 1986

2.1 O Modelo de Atores (Carl Hewitt, 1973)

2.2 A Necessidade da Ericsson e os "Nine Nines"

2.3 A Filosofia "Let it Crash" vs. Programação Defensiva

3. Mapeamento Arquitetural: Cloud Padrão SAS vs. Primitivas BEAM

A Grande Diferença: Polling em Rede vs. Sinalização Reativa

4. Anatomia Microscópica da BEAM: O Subsolo da VM em Código C

4.1 O Process Control Block (PCB)

4.2 A Física da Memória Privada: Crescimento Bidirecional

4.3 Garbage Collection de Cheney Per-Processo (Zero Stop-The-World)

4.4 Taxonomia Avançada de Binários e a Lista MSO List

5. Concorrência Extrema, Lock-Free e o Motor de 2000 Reduções

5.1 Fila de Entrada Lock-Free (sig_inq) e message_queue_data = :off_heap

5.2 O Motor Escalonador (2000 Reduções)

5.3 Task Stealing, Dirty Schedulers e Erlang Monotonic Time

6. A Metáfora Bio-Inspirada: O Sistema de Memória Cognitiva

7. A Matemática Implacável: Latência, Densidade e Custos Financeiros

7.1 A Matemática da Latência (Tempo)

7.2 Densidade Computacional (Memória)

7.3 A Matemática dos Custos Financeiros (Dinheiro)

8. Evidências Empíricas da Indústria (Casos de Estudo)

8.1 WhatsApp: 2 Milhões de Conexões por Servidor

8.2 Bleacher Report: De 150 para 5 Servidores na AWS

8.3 Discord: De 27.000 µs para 4 µs de Latência (Go vs. Rust/Elixir)

9. Conclusão: Coincidência ou Sabedoria Esquecida?

Vamos Continuar a Conversa?

A nuvem chegou às mesmas conclusões que Joe Armstrong e a equipe da Ericsson chegaram em 1986.

A nuvem chegou às mesmas conclusões que Joe Armstrong e a equipe da Ericsson chegaram em 1986.

1. A Grande Convergência Arquitetural

2. A História Se Repete: O Problema da Ericsson nos Anos 80

O Desafio dos Comutadores Telefônicos AXE

A telemetria da prova: `pon_stats.h`

O problema: `O(N × M)`

5. Componente #2 — PON-Timer (Fase 2): Instigações com `timerfd`

7. Componente #4 — PON-Scheduler (Fase 4): Conditions com `eventfd` + `epoll`

9. Componente #6 — PON-Compiler (Fase 6): o `receive` vira Premise

5.1 Fila de Entrada Lock-Free (`sig_inq`) e `message_queue_data = :off_heap`

Reproducible load: `PipelineWorkload`

1. Deduplicate at the source (`Fato`)

2. Coalesce across facts (`Fanout` + `atualizar_lote/1`)

3. Drain the rule mailbox before evaluating (`drain_notificacoes/3`)

4. Fast reads without blocking the fact (`ETS`)