# Trilha 07: Escala e performance, o que sustenta 1,53M tx/dia na AVIV e como a Monetarie supera Data: 2026-07-09. Trilha READ-ONLY do mandato de mapeamento exaustivo AVIV/coreproviders vs cabine Monetarie. Fontes: codigo vivo em `/Users/luizpenha/coreproviders` (branch aviv-hml) e `/Users/luizpenha/monetarie`, mais os documentos de auditoria empirica versionados no proprio repo da AVIV. Nenhuma chamada AWS foi feita nesta trilha; toda afirmacao operacional de producao vem de documento versionado e esta marcada como tal. Convencao: "o codigo faz X" tem arquivo:linha; "o doc afirma X" cita o doc. --- ## 0. Sumario executivo A AVIV sustenta o volume dela (recorde de 1,53M transacoes em 08/07, afirmado no handoff Monetarie `docs/handoff/2026-07-09-incidente-pacs008-canonico-pixin-handoff.md:40`; nos docs da propria AVIV os numeros medidos sao 561k tx/dia em 01/07 e 670.091 PIX-IN liquidados em 24h em 07/07) com uma combinacao de: pools de banco segmentados e grandes (writer 100, reader 50, batch 10), split de leitura por dominio para replica Aurora, checkpoint de saldo com fold horario, uma malha extensa de caches ETS com TTL curto e invalidacao por PubSub, buffers assincronos de auditoria e estatistica, TigerBeetle com pool 1 mais gateway gRPC em Go com batching nativo, Oban com dezenas de crons escalonados por offset, particionamento mensal com retencao por DROP de particao, deploy zero-5xx (lameduck drain, maxPct 117/minHealthy 66, grace 120s) e, acima de tudo, uma disciplina de medicao (suite de benchmark propria com 16 relatorios versionados e auditorias empiricas de producao a cada incidente). O que quebra na AVIV, comprovado nos docs deles: o Aurora writer (100% CPU em 6 de 7 dias, teto de ACU batido, ~30 transacoes PG por deposito PIX-IN), a cauda do TigerBeetle via NIF (stalls transitorios, teto HARD de 64 sessoes, incidente de eviccao ao subir pool para 6), a ingestao por long-poll OnZ (6 slots regulatorios, p50 de entrada 471ms) e o proprio provedor OnZ como teto externo nao dimensionado. A Monetarie ja e estruturalmente superior na entrada (cabine propria ICOM com cadencia de 200ms e leitura de pacs.002 em 24-28ms, mais de uma ordem de grandeza melhor que os 471ms do long-poll OnZ) e ja portou em 04/07 o essencial do arsenal AVIV (checkpoint, 3 caches, watchdogs, poison policy, PromEx, drain, PERF logs, particoes). As lacunas principais para a meta "muito mais volume com latencia menor" sao: (1) zero medicao de envelope proprio (nao temos benchmark nem numero de TPS sustentado); (2) consumo NATS do Core fragil (subscribe efemero sem redelivery, ja causou 24h de surdez); (3) caminho TigerBeetle sem batching ativo (o BatchAccumulator existe no codigo do Core, desenhado para 30k+ TPS, mas esta DORMENTE, zero chamadores); (4) pools de banco pequenos e nao segmentados; (5) prefold do checkpoint diario, nao horario (a AVIV ja pagou um incidente de ACU por isso). --- ## 1. Como a AVIV faz (mecanismo a mecanismo) ### 1.1. Pools de banco segmentados e read/write split por dominio Tres repos Ecto com pools e `application_name` distintos, tunados por env sem rebuild: - Writer `Fluxiq.BaseRepo`: `pool_size` default **100** (`backend/config/runtime.exs:311`), `queue_target: 5_000` / `queue_interval: 1_000` (`runtime.exs:312-313`), `statement_timeout` 30s e `application_name: "fluxiq_main"` (`runtime.exs:319-322`). - Reader `Fluxiq.ReadRepo` (Aurora reader via `READ_REPLICA_URL`, fallback para o writer se a env nao existir, deploy no-op): `pool_size` default **50** (`runtime.exs:335`), com `work_mem` elevado **somente nas sessoes do reader** (default 64MB, `runtime.exs:344-349`), porque as agregacoes de analytics estouravam o work_mem default de 4MB e derramavam para disco. - `Fluxiq.BatchRepo` (pool separado para bulk insert do BatchWriter): `pool_size` default **10**, `queue_target: 10_000` (`runtime.exs:358-360`), `application_name: "fluxiq_batch"`. O split de leitura e por dominio com atoms pre-declarados e fail-safe: `READ_SPLIT_DOMAINS` (ex.: `analytics,reconciliation,statements`) roteia dominios para `Fluxiq.Reads.repo/1`; default vazio = tudo no writer, no-op seguro (`runtime.exs:86-103`; atoms conhecidos pre-declarados em `config/config.exs:14-19`). O deep audit de 05/07 (`docs/audits/2026-07-05-deep-audit-pg-tb-frontends-replica.md`, secao 3) registra `READ_SPLIT_DOMAINS=analytics,reconciliation,statements` vivo em PRD e aponta o P0 deles: o `Reads.with_fallback` devolve a carga ao writer em silencio quando o reader degrada (episodio real de 41% documentado). ### 1.2. TigerBeetle: pool 1, split de sessao, circuit breaker, coalescer e o tb-gateway em Go Aprendizado central da AVIV, provado por incidente: **TB nao escala adicionando clientes**. `TB_POOL_SIZE` default **1** (`runtime.exs:381`). A auditoria `docs/audits/2026-07-07-tb-capacidade-pixin-pixout-analise.md:22` e a secao 5.2 (linhas 216-224) documentam o limite HARD `clients_max = 64` sessoes (doc oficial TigerBeetle) e o incidente de 07/07 (linhas 301-306): subir pool para 6 levou as sessoes a cruzar 64, o servidor logou `clients=64/64 evicting`, os `lookup_account` das sessoes evictadas deram timeout e o cash-out devolveu 503; reverter para pool=3 zerou os 503 em ~3 minutos. A forma correta de escalar e batching (menos clientes, requests maiores). Mecanismos em camadas no caminho TB: 1. **Split leitura/escrita de sessao**: leituras analiticas pesadas roteiam para um cliente dedicado `:tb_bulk` (ON por default, `tb_bulk_read_enabled`, `runtime.exs:391`) para nao fazer head-of-line blocking nas escritas do money path; lookups bulk fatiados em chunks de 500 ids com sleep de 100ms (`runtime.exs:397-404`). 2. **Circuit breaker lock-free** no caminho de leitura (`backend/lib/fluxiq/infra/tigerbeetle/circuit_breaker.ex:1-42`): estado em `:atomics` dentro de `:persistent_term` (leitura sem lock no hot path), threshold 5 falhas consecutivas, cooldown 5s, e **dois breakers independentes** (primary `:tb` vs `:tb_bulk`) para que um storm no cliente de leitura pesada nunca abra o breaker do money path. 3. **Coalescer de depositos** (junta chains concorrentes num unico `create_transfers`): flag `TB_DEPOSIT_COALESCE_ENABLED` default OFF (`runtime.exs:426-436`). O proprio doc da bancada admite que o coalescer manual quase nao dispara (batch ~1) (`docs/audits/2026-07-08-tb-gateway-fase0-bancada.md:40`). 4. **tb-gateway em Go** (dir `tb-gateway/`, gRPC, cliente oficial Go do TB): consolida as sessoes TB de N nos backend em 2-3 instancias e ganha o batching nativo do client oficial, que funde submissoes concorrentes de todos os nos. Fase 0 (bancada, `2026-07-08-tb-gateway-fase0-bancada.md`): 5/5 gates GO; hop gRPC custa +0,31ms no p50; sob rajada o gateway corta a cauda (requests >600ms de 99 para 0, p99 de 862ms para 246ms); sob pressao de CPU o NIF degrada 5-6x no p99 e o Go fica liso. Fase 1 (leitura) e Fase 2 (escrita do deposito PIX-IN) documentadas NO AR nos 4 ambientes (`2026-07-08-handoff-tb-gateway-fase1.md` secao 1; `2026-07-08-handoff-EOD.md` secao 2), com flags `tb_gateway_lookup_enabled` / `tb_gateway_write_enabled` default OFF no codigo (`runtime.exs:444`, `runtime.exs:477`) e ligadas por env nos deploys. Contrato de falha na escrita: erro pos-envio NUNCA cai em fallback silencioso para o NIF (idempotencia por id converge no retry). Criterio de saida da Fase 2 batido: `tb_transient` de 87-96 linhas/h para zero pos-flip. 5. **Hardware**: o EOD de 08/07 (secao 3) documenta a troca do volume gp3 doente do tb-0 (congelava I/O por 12-37s) por volume 6.000 IOPS/500MB/s, com p95 da latencia marginal caindo de 1.507ms para 391ms. Escala de TB tambem e disco. ### 1.3. BalanceCheckpoint com fold HORARIO (a licao do writer ∝ volume ao quadrado) `Fluxiq.UseCases.Payments.PixOut.BalanceCheckpoint` (`backend/lib/fluxiq/use_cases/payments/pix_out/balance_checkpoint.ex:1-45`) mantem por conta um fold acumulado `[cutoff, through_at)` e o hot path so soma o delta apos o fold. O moduledoc registra o incidente que motivou o fold horario: com boundary diario o delta recresce o dia inteiro, cada leitura de saldo re-agrega a fatia do dia da conta quente, custo por chamada cresce com o volume diario enquanto a taxa de chamadas cresce com o trafego, logo carga do writer proporcional ao volume ao quadrado (Aurora writer pinado no teto de ACU em 2026-07-08, 18h30-20h30 BRT). Cron: prefold horario `{"5 * * * *", BalanceCheckpointPrefold}` mais rebuild noturno de self-heal (`runtime.exs:640-643`); mesmo padrao para o fold do treasury (`TreasuryCanonFold`, `runtime.exs:647-648`), que tirou a query #1 do reader (2,5s de scan all-history) para fold + delta de <=2h. O saldo exibido continua `BalanceGuard.safe_balance = min(TB, PG)` e o `BalanceCache` NUNCA entra no pre-check de PIX-OUT (regra explicita no moduledoc, `balance_cache.ex:22-28`). ### 1.4. Malha de caches (ETS, TTL curto, invalidacao PubSub, tudo atras de flag) | Cache | TTL | O que evita | Evidencia | Default | |---|---|---|---|---| | `PixOut.BalanceCache` (display) | 10s | full re-aggregate por poll de `GET /api/external/balance` | `balance_cache.ex:44-46`; flag `runtime.exs:919` | OFF | | `ApiKeys.Cache` | 60s | SELECT de api_key por request externo | `api_keys/cache.ex:35`; flag `runtime.exs:889` | OFF | | `Webhooks.SubscriptionCache` | 60s | SELECT de webhooks por evento no dispatch | `subscription_cache.ex:24`; flag `runtime.exs:118-120` | OFF | | `Limits.GlobalLimitCache` | 300s | SUM em `account_daily_summaries` no PIX-IN (bench-016: p99 do limit_check de 7.179us para 16us) | `global_limit_cache.ex:9`; `benchmark/docs/bench-result-016.md` | vivo | | `External.Pix.TxStatusCache` | 5s pendente / 300s terminal / 30s nil | polling de status por integrador | `tx_status_cache.ex:65-68` | (flag) | | `Settings.Cache` | refresh 5min | leitura de settings | `settings/cache.ex:9` | vivo | | `Infra.IdempotencyCache` | 24h | reprocesso de idempotency key | `idempotency_cache.ex:21` | vivo | | `Admin.Dashboard.Cache` | por chamada, com single-flight (lock 5s) | stampede de dashboards | `admin/dashboard/cache.ex:41-71` | vivo | Invalidacao multi-pod por PubSub broadcast (cada pod mantem ETS local; PubSub so invalida), documentado no `balance_cache.ex:19-21`. `Fluxiq.Infra.EtsCacheInvalidator` centraliza registro de caches invalidaveis (`infra/ets_cache_invalidator.ex:1`). ### 1.5. Buffers assincronos que tiram COMMITs do hot path - **AuditBuffer** (`AUDIT_ASYNC`, default OFF, `runtime.exs:57`): auditoria roteada para lote `insert_all` a cada 1s, elimina o BEGIN/COMMIT extra por mutacao, com durabilidade spill-to-disk + flush no terminate + recovery no boot (comentario integral em `runtime.exs:52-57`). O deep audit de 05/07 lista `audit_async` como confirmado NO LUGAR em PRD (secao 4, final). - **Webhooks StatsBuffer** (`WEBHOOK_STATS_ASYNC`, default OFF, `runtime.exs:66`): troca o UPSERT sincrono por entrega por UM UPSERT por webhook por janela de flush (60s, `runtime.exs:766-768`), matando hot-row counter churn de ~4M UPDATEs/dia em ~50 linhas. Racional de fundo (deep audit 05/07, TL;DR): o gargalo estrutural do writer e transacional, `IO:XactSync` 0,76 AAS e **~30 transacoes PG por deposito PIX-IN** (inbox insert + updates + timeline + processed_messages + upsert tx + qrcode + webhook + oban + audit); rumo a 5M ops/dia o salto vem de coalescer escritas de bookkeeping, nao de mover leitura. ### 1.6. Oban como espinha dorsal operacional - Filas em runtime, todas tunaveis por env (`runtime.exs:731-757`): `default: 10`, `webhooks: 5`, `pix_in_pg_write: 10`, `pix_out_retry: 10`, `onz_lp_process: 6` (deliberadamente igual aos 6 canais LP do BACEN para nao abrir conexoes Aurora alem do necessario; o comentario registra que 6 por no ja processa ~85 msg/s com TB ~70ms), `fee_exports: 1` (job pesado isolado), `accounting: 3`. - Plugins: `Pruner`, `Lifeline` com `rescue_after: 30min` (resgata jobs orfaos de node morto, `runtime.exs:625`) e **`Reindexer` diario as 04:00 BRT** (`runtime.exs:624`), adicionado porque o indice GIN de `oban_jobs.args` chegou a 3GB para ~2,4k jobs vivos e o autovacuum de oban_jobs era o consumidor #1 do writer (comentario em `runtime.exs:620-623`). - **Staggering deliberado dos crons**: as expressoes usam offsets (`1-59/5`, `2-59/15`, `3-59/10`, `14-59/30`...) para que dezenas de sweeps de 5/15min nao colidam no mesmo segundo do writer (`runtime.exs:628-737`). O comentario do `TbPgDriftMonitor` documenta a reducao de `*/5` para `*/15` porque os re-scans constantes derramavam no writer (contencao com deposito PIX-IN). - Safety nets de dinheiro por cron: `PixInRecoveryWorker` */5, `PixInPgWriteJob` enfileirado 30s ANTES do deposito TB como crash-safety (a auditoria 07/07, secao 3.5, prova que os outliers de 30-300s sao exatamente os resgates desse safety net), `TbPgReconciliation` diario, `PixInOrphanReconciliation` */15. ### 1.7. Ingestao OnZ: slots Redis, inbox duravel, poison policy, watchdogs - **Poller LP slot-based**: GenServer por slot com lease Redis SETNX + heartbeat (TTL 15s, heartbeat 5s, standby re-tenta a cada 3s; tudo tunavel por env, `onz/poller.ex:63-70`), teto global de 6 threads LP (limite regulatorio BACEN via OnZ). `receive_timeout` de 10s com historial de regressao documentado no proprio modulo (2s causou cascata de 401; 350ms virou short-polling; `poller.ex:44-62`). - **Inbox duravel**: cada mensagem LP vira linha em `onz_lp_inbox` (INSERT dentro da cadeia serial de ACK do cursor) e o processamento e assincrono por `OnzLpInboxProcessor` (enqueue-driven, fila `onz_lp_process: 6`). Watchdogs por cron de 1-5min: `OnzLpInboxRecovery`, `OnzLpInboxDepthMonitor`, `PixInOkRateMonitor`, `OnzLagMonitor`, `OnzPollerLivenessMonitor`, `OnzDlqDepthMonitor` (`runtime.exs:716-724`), alertando por e-mail de tesouraria. - **Poison policy** no poller (P0-D): falha PERMANENTE consecutiva no mesmo message_id (default 5, `ONZ_POISON_MAX_RETRIES`) sideline duravel (DLQ + linha `poisoned` no inbox) + alerta CRITICO + ACK para o cursor avancar (`poller.ex:33-41`). Sem isso, uma mensagem podre travaria o cursor LP inteiro. - **Retencao do inbox**: purga em batelada no PartitionMaintenance, so linhas terminais `processed` com mais de 30 dias, cap de 1M por execucao, kill-switch por env (`runtime.exs:112-118`). ### 1.8. Rate limiters - **DictBucket** (token bucket espelhando o bucket DICT do BACEN via OnZ, rating G = 25/min): `Guard` GenServer por entidade com scripts Lua no Redis, sync a cada 5s, e uma **matriz de acesso por prioridade vs modo** (normal/warning/critical/emergency x essential/important/optional) que degrada consultas opcionais antes de encostar nas essenciais (`onz/dict_bucket/guard.ex:14-21`); downgrade apos 2 respostas 429 consecutivas (`guard.ex:12`). - **ClientLimiter** per-merchant, fail-open explicito se o Redis cair (a consulta DICT vale mais que o rate limit; `dict_bucket/client_limiter.ex:1-30`). - Fila `pix_out_retry` com snooze alinhado a cadencia oficial de refill do bucket (comentario em `runtime.exs:745-747`); flag `PIX_OUT_RETRY_QUEUE_ENABLED` default OFF (`config/config.exs:9-11`). - `Fluxiq.Infra.Auth.MfaRateLimiter` e `Fluxiq.Services.Sta.RateLimiter` cobrem superficies auxiliares. ### 1.9. Observabilidade: PERF logs, PromEx, OTel, Loki - **PERF logs no cliente OnZ**: `[Onz.Client.PERF] ... HTTP_START/HTTP_END status= ...` com timestamp proprio antes do write no socket (`onz/client.ex:71-88`). Foi essa linha unica parseavel que permitiu medir p50 471ms do long-poll em producao (o comparativo Monetarie de 04/07 usou exatamente esse dado). - **PromEx** com plugins Application/Beam/Phoenix/Ecto/Oban + plugin custom (`backend/lib/fluxiq/prom_ex.ex:7-17`), incluindo counters do tb-gateway (`fluxiq_tb_gateway_{write_fallback,write_ambiguous}_count`, EOD 08/07 secao 2). - **OpenTelemetry** condicionado a `OTEL_EXPORTER_OTLP_ENDPOINT` (`config/config.exs:181-196`), com `opentelemetry_ecto`/`opentelemetry_phoenix`. - **Loki logger** com labels service/env (`runtime.exs:605-614`); Logger com redator de PII e trace context (`config/config.exs:164-167`). - Endpoint HTTP em **Bandit** (`config/config.exs`, bloco `FluxiqWeb.Endpoint`, `adapter: Bandit.PhoenixAdapter`). ### 1.10. Deploy zero-5xx: drain, percentuais e grace - **Drainer lame-duck** (`backend/lib/fluxiq/infra/drainer.ex:1-36`): ultimo filho da arvore, logo termina PRIMEIRO no shutdown; o `terminate/2` segura o listener HTTP aberto por `DRAIN_LAMEDUCK_MS` (default 5s, `runtime.exs:540`) enquanto o ALB propaga a desregistracao, e so entao o Bandit drena os in-flight ate `DRAIN_SHUTDOWN_TIMEOUT_MS` (default 90s, `runtime.exs:541`). O `stopTimeout` do container PRECISA exceder a soma, senao o ECS mata no meio (comentario em `runtime.exs:530-539`). - **Servico ECS**: `health_check_grace_period_seconds = 120` para boot de release Elixir + warmup COSIF/TB (`infrastructure/aws/terraform/ecs.tf:339-347`); Terraform declara `deployment_minimum_healthy_percent = 0` (`ecs.tf:347`), mas o valor VIVO de producao e outro: `minimumHealthyPercent=66 / maximumPercent=117 / desired=6` aplicado por CLI e documentado em `docs/handoff/2026-07-01-SESSION-CLOSE-HANDOFF.md:43` e no runbook `docs/plans/2026-07-08-tb-gateway-fase1-rollout-runbook.md:46` ("roll padrao Aviv PRD, zero-5xx por design"). Divergencia Terraform vs vivo e um gotcha explicito deles. - **slow_start de 30s no target group** so em tenant multi-task (danoso em single-task; racional completo em `variables.tf:178-190`). - Backend roda em **EC2 (t4g.large ARM) e nao Fargate** porque o cliente TigerBeetle exige io_uring (`variables.tf:210-213`); ASG default min/max 1 (`variables.tf:216-227`), em PRD pinado 6 tasks com autoscaling min=max=6 (afirmado na auditoria 5M, achado 4: "sem caminho de scale-out, CPU ja bate 83%"). ### 1.11. Particionamento como alavanca `Fluxiq.Workers.PartitionMaintenance` (cron diario 01:00): pre-cria particoes mensais 3 meses a frente para **7 tabelas** `transactions inflow_requests outflow_requests fee_transactions fee_split_transactions message_timeline audit_logs` (`workers/partition_maintenance.ex:29`), com gate `partitioned?/1` por relkind para cutovers seguros, TTL DELETE apenas para `processed_messages`/`pix_idempotency_keys` (7 dias, `:39-43`) e regra explicita: `audit_logs` NUNCA sofre DELETE, retencao e por DETACH/DROP de particao O(1) (plano A2 do `docs/audits/2026-07-05-aurora-action-plan.md`, maior alavanca isolada: 49GB acumulados, run-rate ~5GB/dia). `transactions` tem PK composta `(id, started_at)` e as queries quentes precisam de bound de particao (a auditoria 5M aponta probes por `end_to_end_id` sem bound varrendo todas as particoes como gargalo confirmado). ### 1.12. Suite de benchmark propria (a arma cultural) Projeto Mix standalone `benchmark/` com path dep no backend (`benchmark/CLAUDE.md`): cenarios PIX-IN direct/HTTP-injection/contention e PIX-OUT, coletor de histogramas ETS pendurado em `:telemetry.span` (zero custo fora do bench), spans por passo do pipeline (audit.insert, cosif.lookup, tb.create_transfer, transaction.insert; `benchmark/README.md`). Disciplina codificada: warmup x100 gate, 3+ rounds no mesmo BEAM (JIT causa 30-50% de variancia), resultado versionado em `bench-result-NNN.md` acumulativo, `GET /bench/flags` para provar o estado das flags do backend vivo. Evolucao medida: 182 TPS no baseline (bench-001) para 960 TPS agregado / **1.129 TPS de pico single-round** (bench-008:78), e bench-016 provando a flag de limite (p99 do limit_check caindo 99,78%). Ha ainda `backend/bench/tb_nif_bench.exs` e `tb-gateway/bench` (gates da bancada Fase 0). ### 1.13. Envelope de capacidade da AVIV (modelo mental, com fontes) Volume medido (docs versionados): - 01/07: **561k tx/dia** (436k PIX-IN + 125k PIX-OUT), 5xx 0,03-0,057%, p50 ALB 13,6ms (`docs/audits/2026-07-01-validacao-profunda-pix-5m.md:9-10`). - 07/07: **670.091 PIX-IN liquidados em 24h**, p50 fim-a-fim 501ms, p95 945ms, p99 2.121ms; pico de 30k tx/30min (~16,7 tx/s inbound no bucket de pico) (`2026-07-07-tb-capacidade-pixin-pixout-analise.md`, secoes 3.1-3.3). - 08/07: recorde de **1,53M tx/dia** (~17,7 tx/s de media; afirmado no handoff Monetarie 2026-07-09:40; NAO ha doc no repo AVIV com esse total, ver secao 7). - Meta interna deles: **5M tx/dia** (~58 tps media, picos projetados 174-290 tps) (`2026-07-01-validacao-profunda-pix-5m.md:10`). Onde o desenho aguenta e onde quebra (ordem dos tetos, conforme a auditoria 5M, secao 1, verificada contra o codigo): 1. **Aurora writer e o binding constraint**: 100% CPU em 6/7 dias, teto ACU batido, ~30 transacoes PG por deposito, `IO:XactSync` como wait #1 (deep audit 05/07). Mitigacoes ja em curso: checkpoint horario, AuditBuffer, StatsBuffer, Reindexer, read split, retencao de audit_logs. Sem coalescer o bookkeeping, 9x nao fecha. 2. **TigerBeetle via NIF**: teto HARD 64 sessoes, stalls VSR de 600ms-3,3s atingindo o deposito, starvation do NIF sob CPU. Mitigacao estrutural: tb-gateway (batching nativo). Piso fisico: disco dos nos TB (troca de volume derrubou p95 de 1.507 para 391ms). 3. **Ingestao LP**: 6 slots globais OnZ (teto regulatorio), 1 inflight por slot, INSERT no writer dentro da cadeia de ACK; processamento 68-136 msg/s por frota vs pico projetado 135-225 msg/s (auditoria 5M, achado 5). 4. **OnZ como teto EXTERNO** nao dimensionado: bucket DICT rating G, bucket PIX-OUT ja saturado em rajada, 6 canais LP (auditoria 5M, achado 6). Este teto a Monetarie NAO tem (participante direto). 5. **ECS pinado em 6 tasks** sem scale-out automatico real (min=max=6). 6. Camadas com folga declarada para 5M/dia: TB no caminho do dinheiro (batch linked por transacao ~4ms/op, teto ~1500 tps), Redis (2,5% CPU, risco = single node SPOF), Oban (`2026-07-01-validacao-profunda-pix-5m.md:39-42`). Latencia estrutural de entrada: p50 471ms / p95 561ms / p99 737ms via long-poll OnZ (medicao PRD anotada em `onz/poller.ex` e consolidada no comparativo Monetarie 04/07), acima da meta BACEN de 500ms no p95/p99. Esse numero e o piso deles: nao ha o que otimizar no lado AVIV sem trocar o modelo de acesso (e por isso o teto de latencia deles e estruturalmente pior que o nosso). --- ## 2. Como a Monetarie faz ### 2.1. Entrada: cabine ICOM propria, resposta direta, durabilidade pre-ACK - Workers CPM/CSM por slot (`pix/backend/apps/spi_service/lib/spi_service/icom/cpm/worker.ex:1-62`): 200 com mensagens = re-poll IMEDIATO (zero sleep); 204 = proximo tick em **200ms** no CPM (`cpm/worker.ex:39`) e 3000ms no CSM (`csm/worker.ex:39`), cadencias do Manual BCB v1.12 4.2. Invariante pre-ACK: o proximo GET (que e o ACK para o BACEN) so sai depois de `AckTracker.persist_batch/2` retornar `{:ok, _}`; queda de Aurora bloqueia o worker e o BACEN retransmite, dedup por MessageId absorve replay (`cpm/worker.ex:57-62`). - Latencia provada: leitura de pacs.002 em **24-28ms** (prova de 03/07 em HML, consolidada no comparativo `docs/reports/2026-07-04-comparativo-aviv-coreproviders-monetarie.html:59-65,133`), aproximadamente 17x melhor que o p50 de entrada da AVIV. - Pools Finch dedicados por endpoint BACEN com mTLS nas conn_opts (SPI primario/secundario size 6, DICT size 12, ARQ size 4, todos `count: 1` para reuso real de conexao; `pix/backend/apps/shared/lib/shared/application.ex:95-107`, racional nas linhas 47-63). ### 2.2. Distribuicao interna: NATS JetStream com outbox e consumers duraveis (na cabine) - Publicacao via outbox duravel (`Shared.Nats.Publisher.publish_async/3`; ADR-009 referenciado em `spi_service/workers/inbound_processor.ex:2365`). - Consumers da cabine via `Shared.Workers.BaseWorker`: push durable com `max_ack_pending = max(3 * concurrency, 20)` (`shared/workers/base_worker.ex:376-382`). Concurrency por worker: `InboundProcessor` **100** (`inbound_processor.ex:78-85`), `OutboundSender` 50, `StatusUpdater` 50, `ReturnProcessor` 20, MED/settlement 5 (grep consolidado nesta trilha). - **Poison policy** portada da AVIV e adaptada a JetStream (`shared/workers/poison_policy.ex:1-40`): contador Redis por identidade de mensagem, 6a falha vai para `monetarie.dlq.poison.` via outbox + ACK, fail-safe = NAK se o Redis cair, zero comando Redis no hot path de sucesso. - **Watchdogs** vivos na arvore do settlement (`settlement_service/lib/settlement_service/application.ex:38-41`): `IcomLagMonitor` (p95 vs ANS 1600ms), `ConsumerLivenessMonitor` (8 duraveis reais), `DlqDepthMonitor`, `PixInOkRateMonitor`. - **PERF logs** padrao AVIV (`spi_service/workers/perf_log.ex:1-27`): `MSG_RECV end2end_ms` (prioridade FctvIntrBkSttlmDt), `MSG_OK duration_ms/handler_ms`, `MSG_FAIL`, parseaveis por Logs Insights, sem PII. - **PromEx** unificado (`shared/lib/shared/prom_ex.ex`, `shared/prom_ex_plugin.ex`) com buckets de end2end no ANS. - **Drainer** portado (`shared/lib/shared/infra/drainer.ex`; lameduck 5s + shutdown 90s, mesmos defaults da AVIV, `pix/backend/config/runtime.exs:321-332`), stopTimeout 100s ja aplicado nos task defs (handoff 04/07, secao 4 item 1). ### 2.3. Core: consumo NATS, TB e o arsenal portado - **Consumo NATS do Core e o ponto fraco**: `Monetarie.Infra.Nats.Consumers.PixConsumer` usa `Gnat.sub` puro (subscribe efemero em subjects planos, `consumers/pix_consumer.ex:53-60`), com retry em memoria (3 tentativas, backoff 1s/2s/4s) e DLQ propria; nao e pull duravel JetStream, logo mensagem publicada com o Core surdo NAO e re-entregue pelo servidor. O incidente de 05-06/07 (Core surdo ao NATS por ~24h, STR0008R2 de R$50k sem credito, recuperado por replay manual do outbox) e a prova viva registrada no CLAUDE.md do repo (secao "Atualizacao 2026-07-06"). O proprio CLAUDE.md registra o gotcha irmao: "JetStream pull do SpbConsumer nunca e puxado (sem reentrega automatica)". - **Pools**: Core `POOL_SIZE` default **30** (`core/backend/config/runtime.exs:255`), um unico repo (`Monetarie.Infra.Repo.Base`), sem reader nem batch pool. Cabine: 4 repos umbrella com `POOL_SIZE` default **5** cada (`pix/backend/config/runtime.exs:218-225`, comentario explicita que e conservador para o budget de conexoes do homolog). - **TigerBeetle**: `TB_POOL_SIZE` default **3** (`runtime.exs:270`), HML rodando com 4 (handoff 04/07, secao 3), pool round-robin lock-free em persistent_term (`infra/tigerbeetle/pool.ex:3-14`). **CircuitBreaker TB vivo** na arvore (`monetarie/application.ex:139`; GenServer com estados closed/open/half_open, threshold 5, reset 30s, `infra/tigerbeetle/circuit_breaker.ex:1-25`). E, muito importante: existe um **`Monetarie.Infra.Tigerbeetle.BatchAccumulator` desenhado para 30.000+ TPS** (batch ate 8.189 itens, flush hibrido 10ms/count, N shards com conexao exclusiva, single-flight, telemetry; `infra/tigerbeetle/batch_accumulator.ex:1-44`) que esta **DORMENTE: zero chamadores e ausente da supervision tree** (grep por `BatchAccumulator.` e `BatchTransfer.` fora do proprio modulo retorna apenas comentarios em `tigerbeetle.ex:394` e `pool.ex:24,82`; nao aparece em `application.ex`). - **Arsenal portado em 04/07** (handoff `docs/handoff/2026-07-04-port-aviv-best-of-breed-handoff.md`): BalanceCheckpoint + prefold 00:10 BRT com anti-retro-datacao (flag `BALANCE_CHECKPOINT_ENABLED`, default OFF em codigo `core runtime.exs:40`, ON em HML `core-api:83`); 3 caches (UsageCache 15min, TxStatusCache 5s/300s/30s, BalanceCache 10s; defaults OFF em `runtime.exs:48-50`, ON em HML); reconciler MED (mode void em HML apos dry-run zero candidatos); logs PERF; watchdogs + poison; PromEx; drain; fee preview. Zero regressao provada por diff de suite com seed fixo. - **Particionamento**: `Monetarie.Workers.PartitionMaintenance` cobre **8 tabelas** (`transactions inflow_requests outflow_requests account_entries cosif_journal_entries message_timeline fee_transactions fee_split_transactions`, `workers/partition_maintenance.ex:56`), criando de `months_ahead 0..3` com comparacao semantica de range contra particoes legadas (`:69-77`); runway de 37 filhos provado no deploy de 04/07 (CLAUDE.md, atualizacao 2026-07-04). Na cabine, `Shared.PartitionManager` mantem particoes de `activity_log`, `login_history` e `monetarie_spi.messages` com lookahead de 60 dias (`shared/partition_manager.ex:19-28`). - **Oban do Core**: filas modestas (`default: 10`, `nats_publish: 10`, `pix_in_pg_write: 10`, demais 2-5; `core/backend/config/config.exs:141-161`). Sem plugin Reindexer, sem staggering sistematico de offsets (verificado no config; os crons do Core nao usam o padrao `k-59/n`). - **Load test assets**: k6 no Core (`core/backend/k6/{core-load-test,core-stress-test}.js`) e o modulo regulatorio `Shared.Bacen.Simulator.CapacityTest` (IN 508: DICT 1.000 GetEntry/60s x10, SPI 2.000 pacs.008/min tier Pequeno; `shared/bacen/simulator/capacity_test.ex:1-28`). NAO ha suite de benchmark do money path com resultados versionados: o comparativo 04/07 registra explicitamente "Ausente; nossos numeros vem de provas pontuais em HML" (`2026-07-04-comparativo...html:156`). ### 2.4. Envelope atual da Monetarie (honesto) - **Não existe medicao de TPS sustentado do nosso money path.** Producao teve 1 pacs.008 recebida (incidente, resolvido) e 0 enviadas (CLAUDE.md, estado 2026-07-09). As provas sao pontuais: leitura pacs.002 24-28ms, GetEntry DICT 200 em 143ms, latencia ICOM por GET 24-28ms. - Referencia regulatoria minima que temos de sustentar como participante direto tier Pequeno: 2.000 pacs.008/min (~33 tps) e 1.000 consultas DICT/min (`capacity_test.ex:5-15`). - Tetos teoricos visiveis no codigo hoje: pool PG do Core 30 conexoes num unico writer; cabine 4x5 conexoes; TB pool 3-4 sessoes sem batching ativo (1 request in-flight por sessao no NIF, mesma mecanica que na AVIV); consumo do Core via subscribe efemero (backpressure e redelivery inexistentes nesse trecho); InboundProcessor da cabine com concurrency 100 e max_ack_pending 300 (folga boa na cabine). - Vantagem estrutural: nosso "long-poll" e o proprio ICOM com cadencia 200ms e resposta direta, sem intermediario; nao temos teto externo de provedor (OnZ) nem bucket DICT de terceiro (temos o bucket do proprio BACEN, que e maior e nosso). --- ## 3. Diferencas estruturais e por que existem | Dimensao | AVIV | Monetarie | Consequencia | |---|---|---|---| | Acesso ao SPI | Indireto via OnZ CloudPIX, HTTP porta 80 sem TLS via peering, long-poll 6 slots | Direto BACEN, mTLS ICP-Brasil, ICOM GET 200ms | Latencia de entrada 471ms vs 24-28ms; AVIV tem teto EXTERNO (OnZ), nos nao | | Broker interno | NENHUM (NATS descomissionado; `config.exs:146` "NATS subsystem decommissioned") | NATS JetStream com outbox duravel + DLQ + poison | AVIV reconstruiu durabilidade com inbox PG + Oban (mais commits no writer); nos pagamos a operacao de um broker (que ja travou uma vez) em troca de replay/desacoplamento | | Durabilidade de ingestao | INSERT em `onz_lp_inbox` dentro do ACK do cursor | `AckTracker.persist_batch` pre-ACK no ICOM | Mesmo principio (durabilidade antes do ACK), implementacoes equivalentes | | Ledger | TB 3 replicas m6g.xlarge + tb-gateway Go (batching nativo) | TB 1 no em HML (3 em PRD, memoria de infra), NIF direto, batcher dormente | AVIV ja resolveu o teto de 64 sessoes; nos ainda nao precisamos, mas vamos precisar | | Banco | Aurora writer+reader, 3 pools segmentados (100/50/10) | Aurora writer unico, pools 30 (Core) e 4x5 (cabine) | Nosso budget de conexao e ~5x menor; sem reader path | | PIX-in | Two-phase ACSP-ACCC, deposito so em ACCC | Legado flag-OFF: BACEN liquida ANTES da pacs.008, credito em `transaction.created -> handle_transaction_ledger` (canonico provado 09/07; TWO_PHASE_PIX_IN PROIBIDO) | O modelo deles existe porque a OnZ entrega ACSP e ACCC separados; no nosso, o dinheiro ja chegou liquidado, uma fase a menos no hot path (vantagem de latencia) | | Deploy | EC2 io_uring, 6 tasks pinadas, maxPct 117/minHealthy 66, grace 120, slow_start 30, drainer | ECS Fargate/EC2 conforme servico, 1 task por servico em HML, drainer + stopTimeout 100 ja aplicados | Falta na Monetarie o desenho multi-task com percentuais zero-5xx como padrao de producao | | Medicao | Suite benchmark versionada + auditorias empiricas por incidente | Provas pontuais; k6 e CapacityTest IN 508 | Maior gap cultural nosso nesta trilha | --- ## 4. O que a AVIV tem de melhor (candidatos a port), com esforco estimado 1. **Suite de benchmark standalone com disciplina de resultado versionado** (`benchmark/`): mesmo stack (Elixir/Phoenix/TB/PG), port quase direto; o comparativo 04/07 ja dizia "portar a suite e barato (mesma linhagem de codigo)". Esforco M (1-2 dias para PIX-in direct + HTTP injection na cabine + Core; collector ETS e generico). 2. **tb-gateway em Go com batching nativo** (`tb-gateway/`): resolve o teto de 64 sessoes e a starvation do NIF, provado com gates de bancada e rollout em 4 ambientes. Port possivel quase byte a byte (o gateway e agnostico do backend; nosso lado Elixir precisa do canal gRPC + flags, ~equivalente ao `tb_gateway/channel.ex` deles). Esforco L (bancada Fase 0 propria antes, como eles fizeram). Alternativa mais barata de primeiro passo: **ativar nosso BatchAccumulator dormente** (ja escrito, precisa entrar na supervision tree + rotear o caminho de deposito + bancada). Esforco M. 3. **Prefold HORARIO do BalanceCheckpoint + fold do treasury** (`runtime.exs:640-648`, `balance_checkpoint.ex` moduledoc): a AVIV pagou um incidente de ACU (08/07 18h30-20h30 BRT) para aprender que fold diario = writer ∝ volume ao quadrado. Nosso prefold e diario (00:10 BRT, handoff 04/07 task A3). Esforco S (mudar cadencia do cron + advance incremental, o desenho deles esta documentado no moduledoc). 4. **AuditBuffer e StatsBuffer** (audit assincrono em lote 1s com spill-to-disk; stats de webhook em delta-flush 60s): ataca diretamente a razao commits/evento (eles mediram ~30 tx PG por deposito). Esforco M cada, ambos com flag OFF e rollback por env. 5. **Oban Reindexer + staggering de crons por offset** (`runtime.exs:624`, expressoes `k-59/n`): o GIN de oban_jobs a 3GB e real em qualquer Oban de alto churn; o staggering e de graca. Esforco S. 6. **Read/write split por dominio com atoms pre-declarados e fallback seguro** (`Fluxiq.Reads`, `runtime.exs:86-103`): pre-requisito para Aurora reader (ja backlog do dono). Portar JUNTO com a telemetria de fallback que eles mesmos apontaram como P0 (fallback silencioso ao writer). Esforco M. 7. **Retencao por DETACH/DROP de particao para tabelas de trilha** (plano A2 do action plan Aurora): nossas `message_timeline`/`audit` vao crescer igual. Esforco M. 8. **Matriz de degradacao do DictBucket** (prioridade vs modo, `guard.ex:14-21`): adaptar aos buckets DICT REAIS do BACEN (somos diretos; nossos limites sao maiores e nossos). Esforco M. 9. **Circuit breaker de leitura TB lock-free com breakers independentes por cliente** (`circuit_breaker.ex` deles usa atomics em persistent_term, o nosso e GenServer com estado central; sob storm de leitura o GenServer vira gargalo/single point). Esforco S-M. 10. **Deploy padrao de producao**: maxPct 117 / minHealthy 66 / grace 120 / slow_start 30 (multi-task). Esforco S (configuracao, mas exige desired >= 3). O que NAO portar (temos melhor ou e proibido): - Long-poll/slots Redis de LP e `Onz*` watchdogs de lag de provedor: nossa entrada e direta e mais rapida; nossos watchdogs equivalentes ja existem (IcomLagMonitor). - Two-phase PIX-in (ACSP->ACCC): PROIBIDO na Monetarie (canonico 09/07: gatilho settled so existe no simulador; ligar = cliente nunca creditado). - Coalescer manual de depositos TB: a propria AVIV mediu batch ~1 e esta aposentando em favor do gateway. - Remocao do broker: o outbox NATS ja nos salvou dinheiro (replay do STR0008R2); o caminho e endurecer o consumo, nao remover o broker. --- ## 5. O que a Monetarie tem de melhor (nao regredir) 1. **Latencia de entrada 24-28ms vs 471ms** (comparativo 04/07, HTML:59-65): consequencia do acesso direto + cadencia CPM 200ms + re-poll imediato com mensagem. Nao introduzir NENHUM intermediario no caminho da transacao (decisao do dono ja registrada). 2. **Durabilidade pre-ACK no ICOM** (`cpm/worker.ex:57-62`): o BACEN so recebe ACK depois do persist; queda de banco nao perde mensagem. Mesma classe de garantia do inbox da AVIV, sem custo extra de long-poll. 3. **NATS JetStream com outbox + DLQ + poison** na cabine: durabilidade e replay que a AVIV nao tem mais (eles reconstruiram por inbox PG + crons). Manter e endurecer (ver P0-2). 4. **Uma fase a menos no PIX-in**: o BACEN liquida antes de entregar a pacs.008; nosso caminho de credito nao espera segunda perna. Menos estados, menos writes, menos cauda. 5. **Sem teto externo de provedor**: nao existe OnZ na nossa frente; nosso rate limit DICT e o do BACEN, nosso canal SPI e o ICOM inteiro. 6. **BatchAccumulator ja desenhado** para 30k+ TPS com shards e flush hibrido (`batch_accumulator.ex:1-44`): a AVIV precisou construir um gateway em Go para ter batching; nos temos o esqueleto em Elixir pronto para bancada. 7. **Particionamento mais abrangente no Core** (8 tabelas vs 7, incluindo `account_entries` e `cosif_journal_entries`, `partition_maintenance.ex:56`). 8. **Watchdogs, poison, PERF logs, PromEx, drain**: ja portados e vivos (secao 2.2/2.3), com melhorias proprias (poison via outbox duravel, watchdogs sem flag, sempre on). --- ## 6. Recomendacoes priorizadas (meta: MUITO mais volume com latencia MENOR) ### P0 (fazer antes de qualquer promessa de capacidade) 1. **Medir o envelope proprio: portar a suite de benchmark da AVIV** (projeto standalone, collector ETS em telemetry spans, disciplina bench-result-NNN versionado, warmup gate, 3 rounds). Sem isso nao existe "aguentar muito mais": nao ha numero hoje. Alvo minimo do primeiro ciclo: TPS sustentado do pipeline pacs.008->credito Core com breakdown por span (persist ICOM, publish NATS, consumer, TB, PG). Referencias: `benchmark/README.md`, `benchmark/CLAUDE.md`, bench-008 (1.129 TPS de pico deles em bancada local). 2. **Endurecer o consumo NATS do Core**: migrar `PixConsumer` (e irmaos) de `Gnat.sub` efemero para consumer duravel JetStream com redelivery e `max_ack_pending` (o padrao ja existe no `Shared.Workers.BaseWorker` da cabine, `base_worker.ex:376-382`); consertar o pull do SpbConsumer que nunca e puxado (gotcha no CLAUDE.md). O incidente de 05-06/07 (24h surdo, 1 evento de R$50k recuperado a mao) e a prova de que o desenho atual nao sustenta volume: sem redelivery, todo blip vira reconciliacao manual. 3. **Decidir o caminho de batching TB com bancada (estilo Fase 0 da AVIV)**: (a) ativar o BatchAccumulator dormente na supervision tree atras de flag, ou (b) portar o tb-gateway Go. Regra aprendida deles (incidente eviccao 07/07): NAO escalar subindo TB_POOL_SIZE; contar sessoes contra `clients_max=64` (nosso pool 3-4 por task x N tasks ja entra na conta ao multiplicar tasks em producao). Gates de bancada deles servem de gabarito: hop, batching, stall, semantica de escrita, starvation. ### P1 (alavancas de volume no banco e no deploy) 4. **Prefold horario do BalanceCheckpoint + rebuild noturno** (hoje diario 00:10 BRT): evitar preventivamente o incidente de ACU que a AVIV sofreu em 08/07 (writer ∝ volume ao quadrado no rush noturno). Receita completa no moduledoc do `balance_checkpoint.ex` deles e crons `runtime.exs:640-648`. 5. **Segmentar pools PG e preparar o reader**: adotar `application_name` por pool (atribuicao de carga em pg_stat_activity), criar BatchRepo para bulk (ETL/exports/reconciliacao) e portar `Fluxiq.Reads` + `READ_SPLIT_DOMAINS` com telemetria de fallback desde o dia 1. Dimensionar POOL_SIZE por medida (a AVIV usa 100/50/10 para 6 tasks; nos hoje 30 e 4x5). 6. **Reduzir transacoes PG por evento de dinheiro**: instrumentar (via benchmark do P0-1) quantos commits o nosso `handle_transaction_ledger` + espelhos + timeline + audit geram por credito; aplicar AuditBuffer (flag OFF) e agrupamento de bookkeeping onde a medicao apontar. A AVIV mediu ~30 e declarou isso o teto estrutural para 5M/dia. 7. **Oban: Reindexer diario + staggering de offsets nos crons do Core** (o config atual nao escalona; a colisao de sweeps de */5 e exatamente o que derrubou o reader deles). 8. **Padrao de deploy de producao zero-5xx multi-task**: desired >= 3 nos servicos de money path, minHealthy 66 / maxPct 117, grace 120s, slow_start 30s, e manter o par drain + stopTimeout >= 100s ja aplicado. Registrar no Terraform (gotcha deles: valores vivos aplicados por CLI divergem do TF e um apply reverte). ### P2 (robustez e higiene de crescimento) 9. **Retencao por particao (DETACH/DROP O(1))** para `message_timeline`, trilhas de auditoria e caixas de entrada, com regra explicita de nunca DELETE em trilha regulatoria (gabarito: plano A2 Aurora deles + nosso PartitionMaintenance). 10. **Breaker TB lock-free (atomics/persistent_term) com breakers independentes por cliente** substituindo o GenServer central no hot path. 11. **StatsBuffer para contadores quentes** (webhooks e equivalentes) quando o volume de webhooks crescer. 12. **Matriz de degradacao por prioridade para o DICT** (adaptada aos buckets reais do BACEN) + fila de retry alinhada a cadencia de refill. 13. **Vigiar os anti-padroes que eles ja pagaram**: monitores fazendo COUNT sem bound de particao no writer (PixInOkRateMonitor deles), probes por e2e sem bound de particao, dashboards mostrando MEDIA acumulada em vez de p50/p95 de janela. --- ## 7. Perguntas abertas / NAO VERIFICADO 1. **O numero 1,53M tx/dia (08/07)**: afirmado no handoff Monetarie (`docs/handoff/2026-07-09-incidente-pacs008-canonico-pixin-handoff.md:40`) e na memoria do projeto como medido por nos em sessao anterior via AWS. Nesta trilha (read-only, sem AWS) NAO encontrei documento no repo AVIV com esse total; os maiores numeros versionados la sao 561k/dia (01/07) e 670k PIX-IN/24h (07/07). Nao re-derivado. 2. **Estado LIVE das flags AVIV em PRD** (audit_async, stats_async, caches, gateway write): os handoffs afirmam (ex.: Fase 2 ON em `:210/:212`, audit_async confirmado no deep audit), mas o valor vivo atual nao e verificavel por codigo. Distingui default de codigo vs afirmacao de doc em cada citacao. 3. **maxPct 117/minHealthy 66**: valor VIVO por CLI documentado em handoff; o Terraform diz `deployment_minimum_healthy_percent = 0` (`ecs.tf:347`). Qual esta valendo hoje em PRD deles nao e verificavel daqui. 4. **TigerBeetle da Monetarie em PRD**: a memoria de infra registra TB x3 em producao (fase 3, 07/07); nao verifiquei nesta trilha (seria chamada AWS). O dimensionamento de disco dos nossos nos TB (a licao do gp3 doente deles) fica como pergunta para a trilha de infra. 5. **Concurrency real de producao dos nossos consumers**: os valores citados sao defaults de codigo; nao ha env override visivel nos configs, mas as task definitions vivas podem divergir. 6. **Fluxiq.Bench.FeatureFlags e endpoints /bench**: existem no backend AVIV (`backend/lib/fluxiq/bench/feature_flags.ex`, rota `GET /bench/flags` citada no CLAUDE.md do benchmark); nao rastreei se os endpoints ficam expostos em prod ou so em dev (gate por env presumivel, NAO VERIFICADO). 7. **Numero de transacoes PG por credito PIX-in na Monetarie**: desconhecido (nunca medido). E a primeira pergunta que o benchmark do P0-1 deve responder. 8. (Resolvida durante a escrita) `webhook_subscription_cache_enabled` da AVIV tem default false (`runtime.exs:118-120`, `WEBHOOK_SUB_CACHE_ENABLED`), TTL 60s.