Forem: Davi Orlandi

GO profiling using pprof

Davi Orlandi — Mon, 15 Dec 2025 02:07:42 +0000

Have you ever spent nights trying to understand why your application is using so many resources? Your CPU is on fire, memory keeps growing, latency goes up… and the code looks fine. Probably, you're guessing instead of verifying.

In this article, we'll see how to verify possible memory leaks, unused resources and bad optimized code using the Go built-in profiling tool pprof.

What is pprof?

pprof is Go builtin profiling tool that allows you to collect and analyze runtime data from your application, such as CPU usage, memory allocations, goroutines, and blocking operations.

In simple terms, pprof answers questions like:

Why is my application slow?
Where is CPU time being spent?
What is allocating so much memory?
Are goroutines leaking?

Spoiler: pprof does not magically optimize your code. It just tells you where you messed up.

How pprof works

pprof works in two steps, collect (where we can collect metrics from our applicaton) and analyze (where we analyze the collected metrics using the go tool pprof).

At runtime, Gosamples execution and records metrics. These samples are aggregated into profiles that can be visualized and explored using pprofcommands.

You might think this is a lot like traces, but under the hood, Go does statistical profiling, that means your program is periodically interrupted and the runtime records what was running at that exact moment. Overtime these snapshots form a accurate picture of resources use.

A simple way to enable proffiling in you app is using an http server, take an example:

This exposes profiling endpoints under /debug/pprof/, such as /debug/pprof/profile (CPU), /debug/pprof/heap (Memory), etc.

Collecting profiles

When you hit a pprof endpoint like /debug/pprof/profile, what you get back is not a report, it’s a binary blob. If you try to open it in the browser, you’ll download a file and see what looks like complete garbage.

At first, that's correct, this endpoint returns a serialized pprof profile (a protobuf, usually gzip-compressed) that contains raw sampled data collected by Go runtime, stack traces, counters, timestamps. Not charts. Not tables. Not answers. This binary mess is not meant for humans.

And that’s where pprof comes in.

pprof is the tool that takes this raw, unreadable data and decodes, aggregates, correlates and turns it in a human readable output.

Analyzing profiles

Well, let's start to analyze our profilling output. The first step is install the pprof cli using this command below:

go install github.com/google/pprof@latest

You should see something like that:

Now, we'll need the web server running and try to get a profiling with this command below (CPU Profile, 10 seconds):

go tool pprof http://localhost:8080/debug/pprof/profile?seconds=10

If you made everything right and waited for 10 seconds, you should get interactive shell. This is where the raw profile data becomes actionable. Once inside pprof, you can execute many commands, such as top, list, web, etc. (check the options here)

The Big Bad Boy

Imagine we have an endpoint using a lot of CPU, the "Big Bad Boy", for study proposal, i'll use a /work endpoint.

With our app running, hit the /work endpoint from another terminal or using curl, trigger some CPU load:

curl http://localhost:8080/work

You can repeat it a few times or use a load tool like hey or ab to generate more pressure.

Now, collect a 10-second CPU profile from the running server:

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=10

Inside the pprof shell, you can show top functions consuming CPU using top.

You wi'll se an output like:

(pprof) top 
Showing nodes accounting for 7470ms, 92.45% of 8080ms total
Dropped 2 nodes (cum <= 40.40ms)
Showing top 10 nodes out of 35
      flat  flat%   sum%        cum   cum%
    2030ms 25.12% 25.12%     2030ms 25.12%  math.archExp
    1570ms 19.43% 44.55%     1570ms 19.43%  math.IsInf (inline)
    1500ms 18.56% 63.12%     2830ms 35.02%  math.log
     560ms  6.93% 70.05%     5800ms 71.78%  math.pow
     430ms  5.32% 75.37%     1050ms 13.00%  math.sin
     330ms  4.08% 79.46%      330ms  4.08%  runtime.pthread_cond_signal
     320ms  3.96% 83.42%     1560ms 19.31%  math.frexp
     290ms  3.59% 87.00%      290ms  3.59%  math.Float64frombits (inline)
     220ms  2.72% 89.73%      220ms  2.72%  math.IsNaN (inline)
     220ms  2.72% 92.45%      230ms  2.85%  math.normalize (inline)

We can se a lot of math packages operations right now, but we don't know where those operations are used. So, let's run top command again with -cum (cumulative) flag.

(pprof) top -cum
Showing nodes accounting for 2170ms, 26.86% of 8080ms total
Dropped 2 nodes (cum <= 40.40ms)
Showing top 10 nodes out of 35
      flat  flat%   sum%        cum   cum%
     110ms  1.36%  1.36%     7750ms 95.92%  main.heavyComputation
         0     0%  1.36%     7750ms 95.92%  main.main.func1
         0     0%  1.36%     7750ms 95.92%  net/http.(*ServeMux).ServeHTTP
         0     0%  1.36%     7750ms 95.92%  net/http.(*conn).serve
         0     0%  1.36%     7750ms 95.92%  net/http.HandlerFunc.ServeHTTP
         0     0%  1.36%     7750ms 95.92%  net/http.serverHandler.ServeHTTP
         0     0%  8.29%     2830ms 35.02%  math.Log (inline)

Spotted! The main.heavyComputation consuming 95.92% of the total CPU, well, that is our “Big Bad Boy.”

You can do the same for memory, block, mutex, and goroutine profiles

Memory (heap) – see allocations and leaks:

go tool pprof http://localhost:6060/debug/pprof/heap

Goroutines – detect leaks or deadlocks:

go tool pprof http://localhost:6060/debug/pprof/goroutine

Block – see time spent waiting on channels, mutexes, etc.:

go tool pprof http://localhost:6060/debug/pprof/block

Mutex – see contention hotspots:

go tool pprof http://localhost:6060/debug/pprof/mutex

All of these can be analyzed in the same way (top, list, web, svg). The web and svg commands produce graphical visualizations (requires Graphviz), making it much easier to spot hotspots.

Visualization (Graphviz required)

Graphical visualizations make it much easier to spot CPU or memory hotspots quickly, for that, we need install Graphviz and open source graph visualization software.

web: opens a call graph in your browser
svg: outputs an SVG call graph
pdf: outputs a PDF graph

Don’t spray and pray

pprof has multiple profile types because performance problems love to hide in different places. Each type answers a different question:

CPU – where time is spent
Heap – memory usage and leaks
Goroutines – leaks or deadlocks
Block – wait times
Mutex – contention

Always choose the profile that matches the problem.

ADDITIONAL: Profiling in Kubernetes

If your app runs in a Kubernetes cluster, you can port-forward the pprof port from your pod:

kubectl port-forward deploy/my-app 6060:6060

Access pprof locally:

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=10

Analyze interactively as usual (top, list).

Useful Links & References

Go pprof docs: https://pkg.go.dev/net/http/pprof
Runtime profiling: https://pkg.go.dev/runtime/pprof
go tool pprof guide: https://go.dev/doc/diagnostics#profiling
Official Go blog post about pprof: https://go.dev/blog/pprof

So, Thanks!

If this article saved you even one late night of guessing and blaming the garbage collector, it already did its job 😄. Thanks for reading!

See you soon ;)

Getting Started With Linux

Davi Orlandi — Sun, 14 Dec 2025 22:36:44 +0000

This article is intended as a study-oriented, introductory overview of Linux. It intentionally covers very basic concepts and simplifies some topics to help beginners build an initial mental model. It is not meant to be exhaustive or deeply technical, but rather a starting point for further exploration.

Base needed knowledge:

GNU: GNU is a predecessor of Linux and a free open-source unix-like operating system.

Kernel: Kernel is the core system of an operational system, it acts as a bridge through software and hardware, managing system resources (CPU, memory, peripheral devices). Although we use the same Linux to describe the whole operating system, it's only refers to the kernel.

Whats is Linux?

Linux is an open-source operating system kernel originally created by Linus Torvalds. In practice, when people say “Linux,” they are usually referring to a complete operating system made of the Linux kernel combined with tools, libraries, and others softwares from the GNU project.

A linux system is divided in three layers:

Hardware: This includes the physical resources of your machine, such as CPU, memory, peripheral devices, etc.

Linux Kernel: Is the core of the operating system, managing the hardware and facilitates communication between software and hardware.

User Space: This is the environment where the users interacts with the system, using applications and command line interfaces.

What is a Linux distribution?

A distribution is a bundle of the Linux kernel with some specific softwares, tools, system utilities, libraries and applications. Essentially a distro is a complete, ready-to-use operating system built around the Linux Kernel.

Debian:

Debian is an operating system composed entirely of free and open-source software, it's one of the most respected projects in community.

Package Management

Debians uses a powerful package management tool called apt (Advanced Package Tool). The system maintain a massive repository of pre-compiled software packages.

Red Hat Enterprise Linux (RHEL)

RHEL is a commercial linux distribution developed by the Red Hat Team, build to provide long-term stability, security and professional support.

Package Management

RHEL uses RPM (Red Hat Package Manager) format for its software packages, for managing this packages, it provides powerful package managers like YUM (Yellowdog Updater, Modifier) and its sucessor, DNF (Dandified YUM).

Ubuntu

Ubuntu is probably the most famous famous linux distribution, it's and excellent entry point for anyone looking to get started with Linux.

Package Management

As a Debian-based operating system, Ubuntu utilizes the core Debian package management system. This means it uses the apt (Advanced Package Tool) command-line utility to handle software installation, updates, and removal, giving users access to a vast repository of free and open-source software.

Fedora

Fedora is and equivalent to Ubuntu but developed by Red Hat team, built on our foundation instead of Debian.

Package Management

Fedora utilizes the RPM package format and manages software with the DNF (Dandified YUM) package manager. DNF is a powerful and easy-to-use command-line tool for installing, updating, and removing software packages on the system.

The shell

The is a program that accepts you typed commands and passes them to the operating system. If you i've used a GUI (Graphical User Interface), you might have encountered applications like "Terminal" or "Console." the are simply programs that open a shell session for you.

BASH (Bourne Again Shell)

Bash is the default shell for most Linux distros. While other shells like ksh, zsh, and tsch exist, mastering Bash provides a solid foundation for working with any Linux system.

When you open a terminal, you'll see the shell prompt, Its appearance can vary between distros but it typically follows this format: username@hostname:current_directory$.

Yeah, i used a MacOS Terminal screenshot, don't care its not relevant.

The $ symbol at the end indicates that the shell is ready to accept commands, you do not type this symbol when entering commands, it is purely informational!

How the hell does this work?
Well, just paste this command echo "I love Linux" and you'll see "I love Linux" as the output into console.

Filesystem basics

Linux uses single root filesystem, meaning everything starts from / (root). There are no drive letters like C: or D:, all storage devices are mounted into the same tree.

Common directories

/ — root of the filesystem
/home — user home directories
/etc — system configuration files
/var — variable data (logs, cache, spool)
/usr — user-installed software and libraries
/bin and /sbin — essential system binaries

In Linux, everything is treated as a file, including devices, processes, and sockets.

Paths

A path is the location of a file or directory inside the filesystem. It tells the system where something is in the directory tree.

Absolute paths starts from / like /home/user/projects and relative paths without as like projects/my-app.

Useful navigation commands:

pwd   # show current directory
ls    # list files
cd    # change directory

Permissions & users

Linux is a multi user operating system, built with security in mind from the start, so, every file and directory has an owner, a group, and a set of permissions.

You can permissions in you computer with ls -l:

Root is the superuser, with full-access, otherwise, normal users have limited permissions. You can run some commands as root user using sudo before any command.

Permissions are a core concept in Linux and one of the main reasons servers are secure by default.

Networking basics

Linux provides powerful built-in tools to inspect, debug, and interact with networks. Networking is a fundamental skill, especially for servers, containers, and cloud environments.

Network concepts

IP address: identifies a machine on a network
Ports: identify services running on a machine
Protocols: rules for communication (HTTP, TCP, UDP)

Common networking commands:

ping "url.com"

curl "url.com"

wget "url.com/file.zip"

ip a

Useful links & references

GNU project: https://www.gnu.org
Linux Kernel documentation: https://www.kernel.org/doc/html/latest/
Filesystem Hierarchy Standard (FHS): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
Debian official docs: https://www.debian.org/doc/
APT documentation: https://wiki.debian.org/Apt
Red Hat Enterprise Linux docs: https://access.redhat.com/documentation
DNF documentation: https://dnf.readthedocs.io/en/latest/
Ubuntu documentation: https://help.ubuntu.com/
Fedora documentation: https://docs.fedoraproject.org/
Bash manual: https://www.gnu.org/software/bash/manual/
Linux permissions reference: https://www.redhat.com/sysadmin/linux-file-permissions
Linux networking overview: https://www.kernel.org/doc/html/latest/networking/index.html

Thanks!

Thanks for reading this article. I hope it helped clarify the core concepts behind Linux and gave you a starter foundation to keep exploring the ecosystem.

See you soon ;)

RAG with MongoDB Vector Search PART 1

Davi Orlandi — Thu, 11 Dec 2025 23:24:54 +0000

What is RAG?

Retrieval-augmented generation (RAG) is a technique that enables large language models (LLMs) to retrieve and incorporate new information. RAG feeds contextual data to the LLM to deliver more accurate and grounded answers.

Why Vector Search Matters in RAG?

Traditional keyword search breaks down when queries are vague, paraphrased, or semantically rich. Vector search solves this by representing text as high-dimensional embeddings that encode meaning rather than literal wording.

Embedding converts documents and user queries into high-dimensional vectors that capture their semantic meaning.
Indexing then uses these vectors to build an approximate nearest-neighbor (ANN) structure such as HNSW, IVF-Flat, or PQ, enabling efficient similarity search.
Retrieval embeds the incoming query and compares it against the indexed vectors, returning the closest matches based on semantic similarity.

Let's think about it:

Imagine we have these sources of data:

Source 1
"Hono is a fast, lightweight JavaScript framework built on Web Standards. It focuses on low overhead, edge-friendly execution, and a minimal API surface."

Source 2
"Elysia is a Bun-optimized web framework that provides strong typing, schema validation, and excellent performance. It is designed for building scalable HTTP services with good developer ergonomics."

Source 3
"Express is a minimalistic and widely adopted Node.js framework. It is commonly used to build REST APIs because of its simplicity, extensive ecosystem, and flexible middleware model."

Now imagine a user searches for the following query:
"How can I build a backend service in JavaScript, with better Bun runtime integration?"

When this query is embedded, the resulting vector represents concepts such as backend service, API development, HTTP frameworks, and JavaScript server-side technologies.

Most modern embedding models (Voyage, OpenAI, HuggingFace, etc.) generate vectors between 512 and 3072 dimensions. See an example:

[
  0.0182, -0.0925, 0.0441, 0.0107, -0.0713, 0.1234, -0.0089, 0.0562,
  -0.0041, 0.0977, 0.0229, -0.0335, 0.1412, -0.0611, 0.0054, 0.0883,
  -0.0122, 0.0745, -0.1099, 0.0671, 0.0144, -0.0528, 0.0995, -0.0173,
  0.0811, -0.0442, 0.0368, 0.1210, -0.0075, 0.0932, -0.0661, 0.0152,
  0.0473, -0.0891, 0.1329, 0.0287, -0.0174, 0.0721, -0.0554, 0.1012,
  0.0069, -0.0312, 0.1184, -0.0251, 0.0526, 0.0048, -0.0903, 0.1301,
  0.0110, -0.0782, 0.0433, 0.0271, -0.0622, 0.0999, -0.0148, 0.0711,
  0.0835, -0.0222, 0.0579, -0.0384
]

Vector search then compares this query vector with the vectors generated from the sources above using the index.

The similarity search identifies which sources are semantically closest to the intent of the query and retrieves them. In this case:

Source 2 (Elysia) is likely to rank highest because it explicitly mentions Bun optimization and scalable HTTP services—concepts directly aligned with building a backend service in JavaScript with strong Bun runtime integration.

Source 3 (Express) would typically appear next, as it strongly relates to backend development and REST API construction, even though it is not tailored to Bun.

Source 1 (Hono) remains relevant but ranks lower because its description emphasizes minimalism and edge-friendly execution rather than Bun-specific integration or backend-focused features.

A vector search result might look like this:

[
  {
    "text": "Elysia is a Bun-optimized web framework that provides strong typing, schema validation, and excellent performance. It is designed for building scalable HTTP services with good developer ergonomics.",
    "score": 0.91
  },
  {
    "text": "Express is a minimalistic and widely adopted Node.js framework. It is commonly used to build REST APIs because of its simplicity, extensive ecosystem, and flexible middleware model.",
    "score": 0.78
  },
  {
    "text": "Hono is a fast, lightweight JavaScript framework built on Web Standards. It focuses on low overhead, edge-friendly execution, and a minimal API surface.",
    "score": 0.61
  }
]

Why use MongoDB Atlas Vector Search?

MongoDB Atlas Vector Search brings vector similarity, metadata filtering, and document storage into a single, unified system.

Instead of splitting your stack between a vector database and an operational database, Atlas lets you keep embeddings, raw documents, and application data side-by-side. This removes the overhead of synchronizing two systems, reduces latency, and simplifies your architecture.

For RAG pipelines, this matters: you can store the original sources, their embeddings, and any contextual metadata (tags, timestamps, access rules, versions) all in one place and query everything in a single round trip.

How MongoDB Vector Search Works

MongoDB stores your embeddings inside collections as arrays of numbers, just like any other field. When you enable vector search on that field, Atlas builds an ANN index optimized for fast semantic similarity lookup.

When a query comes in, Atlas uses your embedded input (usually through your app or an LLM workflow), compares the query vector against the indexed vectors, and returns the documents with the smallest distance.

Creating a Vector Search Index in MongoDB Atlas

To enable vector search in MongoDB Atlas, you start by defining a vector index on the field that stores your embeddings. This index tells Atlas how to structure the ANN graph (HNSW) and what similarity metric to use. A typical index definition looks like this:

{
  "mappings": {
    "dynamic": false,
    "fields": {
      "embedding": {
        "type": "knnVector",
        "dimensions": 1536,
        "similarity": "cosine"
      }
    }
  }
}

Here, embedding is the field where each document stores its vector representation. The dimensions value must match the size of the embedding model you use, and similarity defines how distance is calculated during retrieval.

Once indexed, MongoDB can perform vector search queries through the $vectorSearch stage. A minimal example looks like this:

{
  "$vectorSearch": {
    "index": "frameworks_vector_index",
    "path": "embedding",
    "queryVector": [/* query embedding values */],
    "numCandidates": 50,
    "limit": 3
  }
}

Behind the scenes, Atlas takes your queryVector, traverses the HNSW graph, and identifies the closest nodes based on the configured similarity metric.

For the earlier query, Atlas would receive the embed user input, compare it against all stored embeddings, and return the most semantically aligned frameworks, just like in the example shown above. Because the retrieval happens inside the same database where your documents and metadata live, your RAG pipeline can immediately assemble the final context to feed into the LLM.

A critical requirement: your embedding model must be the same for both stored documents and incoming queries. Mixing models or versions breaks vector compatibility and degrades similarity search. Always embed with the same model.

This was a brief overview of how RAG, vector search, and MongoDB Atlas fit together in a practical workflow. I will continue publishing more articles exploring RAG architectures, vector indexing strategies, hybrid search, retrieval optimization, and real-world patterns using MongoDB Atlas.

Documentation

MongoDB Atlas Vector Search
https://www.mongodb.com/docs/atlas/atlas-search/vector-search/

MongoDB University (free courses)
https://learn.mongodb.com/

Voyage AI
https://docs.voyageai.com/

See you soon ;)

Como implementar um Ledger em sístemas distribuídos

Davi Orlandi — Sun, 21 Sep 2025 15:09:59 +0000

O que é um ledger?

Considere um Ledger como um "livro da verdade", por exemplo, uma planilha contábil de uma empresa, onde são registradas todas as transações que aconteceram. Assim como em uma planilha contábil, não editamos ou removemos registros, apenas adicionamos novas entradas. Isso nos garante a imutabilidade, que é um ótimo princípio em sistemas financeiros. A forma mais comum de tratar isso é por meio de eventos de entrada e saída, junto ao montante de valor correspondente para cada transação.

Como fazer?

Primeiramente, é uma prática essencial manter um Ledger distinto para cada tipo de moeda, como BRL ou USD, para simplificar radicalmente a lógica de negócio e os cálculos. Além disso, para prevenir o processamento duplicado em um sistema distribuído, cada operação deve ser acompanhada de uma chave de idempotência única.

O gerenciamento da concorrência é outro pilar para evitar inconsistências no saldo. Uma abordagem é o lock otimista, que utiliza um campo de versionamento como version ou last_sequence. A alternativa é o lock pessimista, que garante acesso exclusivo ao Ledger através de um serviço externo como Redis.

Persistência e Concorrência

A persistência do Ledger pode ser implementada em um banco de dados como o MongoDB. Para lidar com bloqueios otimistas, utilizamos um campo como last_sequence no próprio documento do Ledger. Para o bloqueio pessimista, a recomendação é um serviço de cache distribuído onde a latência seja a menor possível, como o Redis.

A chave de idempotência, por sua vez, depende da estrutura do sistema, mas geralmente é composta por uma combinação de dados como timestamp + from + to + amount. Essa chave pode ser armazenada em um cache distribuído com um TTL (Time To Live).

Lidando com Dinheiro em Sistemas Distribuídos

Por que usar `int` e não `float`?

Nunca use tipos de ponto flutuante (float) para armazenar dinheiro. A solução padrão é trabalhar com inteiros, armazenando o valor na menor unidade da moeda (ex: R$ 123,45 é armazenado como o inteiro 12345). Todas as operações matemáticas são feitas com esses inteiros, eliminando erros de precisão.

Estrutura para Múltiplas Moedas

Valores monetários devem ser representados por uma estrutura que combine o montante e a moeda, seguindo o padrão ISO 4217. Essa estrutura deve conter o amount (inteiro) e a currency (ex: "BRL"), prevenindo erros como somar diretamente dólares com reais.

Aplicando o Lock Otimista e Transações

Para garantir a consistência, o processo de registrar uma transação deve ser atômico. Aqui está um passo a passo mais detalhado de como implementar o fluxo completo:

Verificação de Idempotência (Fail Fast): Antes de iniciar a transação no banco de dados, verifique a chave de idempotência em um cache rápido como o Redis. Se a chave já existir, significa que a operação já foi processada, e você pode retornar o sucesso imediatamente, evitando trabalho desnecessário.
Início do Loop de Tentativa (Retry Loop): Como o lock otimista pode falhar, toda a lógica de negócio deve rodar dentro de um loop que tentará a operação algumas vezes (ex: 3 tentativas) antes de desistir.
Leitura do Estado Atual: Dentro do loop e de uma nova transação do MongoDB, leia o documento do Ledger para obter seu balance e last_sequence atuais.
Cálculo em Memória: Calcule o novo saldo na sua aplicação. novo_saldo = saldo_atual + valor_da_transação.
Execução da Escrita Atômica: Execute as duas operações de escrita dentro da mesma transação:

insertOne na coleção transactions com os dados da nova movimentação.
updateOne na coleção ledgers. Este update é a chave do lock otimista: ele deve buscar pelo _id e pela last_sequence que você leu no passo 3. A atualização irá então modificar o balance e incrementar o last_sequence.

Resultado:

Sucesso: Se o updateOne encontrar o documento e a transação for concluída (commit), significa que não houve conflito. Você pode sair do loop e retornar o sucesso.

Falha: Se a transação falhar porque o last_sequence não correspondeu, significa que outro processo alterou o Ledger. O loop de tentativa continuará para a próxima iteração, reiniciando o processo a partir do passo 3. É uma boa prática adicionar um pequeno tempo de espera (backoff) entre as tentativas.

Se o loop se esgotar sem sucesso, a operação falhou e um erro deve ser retornado ao cliente.

Como ficam meus dados?

ledgers

{
 "_id": ObjectId(),
 "balance": {
    "amount": 12345,
    "currency": "BRL"
 }, 
 "last_sequence": 1,
 "last_transactions":[
   {
     "_id": ObjectId(),
     "ledger_id": ObjectId(),
     "timestamp": UnixTime,
     "sequence": 1,
     "change": {
        "amount": 5000,
        "currency": "BRL"
     },
     "idempotency_key": "timestamp-from-to-amount"
   }
 ]
}

transactions

{
     "_id": ObjectId(),
     "ledger_id": ObjectId(),
     "timestamp": UnixTime,
     "sequence": 1,
     "change": {
        "amount": 5000,
        "currency": "BRL"
     },
     "idempotency_key": "timestamp-from-to-amount"
}

Considerações Finais

Construir um Ledger confiável se baseia em quatro pilares essenciais:
Imutabilidade, garantindo um histórico de transações que é apenas de adição (append-only);
Precisão, usando inteiros para cálculos monetários e evitando erros de ponto flutuante;
Consistência, através de transações atômicas com controle de concorrência como o lock otimista;
Idempotência, para proteger o sistema contra operações duplicadas.

Uma vez que esses fundamentos estão sólidos, o próximo passo na evolução do sistema é pensar em escalabilidade. Para Ledgers com milhões de transações, técnicas como Snapshots (fotos periódicas do saldo) para otimizar a performance de leitura e o arquivamento de transações antigas tornam-se cruciais para manter o sistema performático a longo prazo.

Arquitetura Baseada em Espaço (SBA - Space-Based Architecture)

Davi Orlandi — Sat, 23 Aug 2025 20:22:37 +0000

A Arquitetura Baseada em Espaço (SBA) é uma abordagem de design de software que organiza o sistema em torno do conceito de "espaços", que são unidades de funcionalidade isoladas e autônomas. Contrasta com as abordagens mais comuns de serviços de enfileiramento de mensagens, onde os componentes interagem trocando mensagens através de um message broker. Em vez disso, a SBA utiliza um paradigma de espaço de tuplas, onde os componentes interagem trocando tuplas ou entradas através de um ou mais espaços compartilhados.

Imagine que, enquanto um message broker é como uma conferência acadêmica onde os apresentadores falam em ordem, um espaço de tuplas é como uma unconference, onde todos os participantes podem escrever em um quadro branco comum simultaneamente e ver tudo ao mesmo tempo.

O objetivo principal da SBA é alcançar a escalabilidade linear de aplicações stateful e de alto desempenho. Isso é feito construindo aplicações a partir de um conjunto de unidades de processamento (PUs - Processing Units) auto-suficientes e independentes, permitindo que a aplicação escale com a adição de mais unidades. A SBA segue princípios de REST, SOA e EDA, e incorpora elementos de grid computing.

Componentes Essenciais da SBA

A SBA é composta por três partes fundamentais:

Unidades de Processamento (PUs - Processing Units): São os blocos de construção básicos do sistema. Cada PU contém sua própria lógica e dados necessários para as tarefas. Elas são independentes, escaláveis e projetadas para serem replicadas, garantindo que outras unidades possam assumir se uma falhar.
Espaço (Space): É onde todos os dados são mantidos, atuando como uma grande grade de memória distribuída onde as informações são armazenadas e compartilhadas. Todas as PUs podem acessar este espaço, garantindo a operação contínua do sistema mesmo com falhas em partes individuais.
Roteador (Router): Funciona como um diretor de tráfego, assegurando que as requisições dos usuários cheguem à PU correta para serem processadas, mantendo o balanceamento e a eficiência das tarefas.

Princípios da Arquitetura Baseada em Espaço

A SBA é construída sobre alguns princípios-chave que garantem sua eficácia:

Distribuição: Dados e tarefas de processamento são espalhados por múltiplos nós, otimizando a alocação de recursos e acomodando cargas de trabalho variáveis. Isso permite escalabilidade horizontal, onde mais nós podem ser adicionados para gerenciar o crescimento da carga.
Desacoplamento: Os componentes operam independentemente uns dos outros, permitindo escalabilidade e tolerância a falhas, pois cada elemento pode ser escalado sem afetar o resto do sistema.
Assincronia: Nós se comunicam e coordenam sem esperar por respostas instantâneas, o que aumenta a responsividade e a escalabilidade ao liberar recursos.
Resiliência: O sistema é capaz de tolerar falhas e manter a funcionalidade através da replicação de dados e tarefas de processamento. Isso garante que funções críticas não sejam afetadas e que o sistema se recupere rapidamente.
Orientada a Eventos: Frequentemente, a SBA utiliza arquiteturas orientadas a eventos para promover comunicação e coordenação assíncrona entre os componentes, permitindo que eles reajam a mudanças em tempo real.

Vantagens da SBA

As principais vantagens da SBA incluem:

Alto grau de isolamento e autonomia: Cada "espaço" é independente, o que facilita o teste, a implantação e a evolução do sistema. Desenvolvedores podem trabalhar em diferentes espaços concorrentemente.
Escalabilidade e desempenho aprimorados: A capacidade de escalar cada espaço independentemente permite um melhor controle dos recursos e um desempenho otimizado para lidar com grandes volumes de dados e interações de usuários.
Resiliência e tolerância a falhas: Através da replicação de dados e tarefas, os sistemas SBA podem continuar operando mesmo se nós individuais falharem, garantindo um tempo de atividade contínuo.
Mitigação de gargalos de banco de dados: Ao carregar grandes blocos de dados na memória (cache) na inicialização do "espaço", a SBA pode reduzir significativamente a carga no banco de dados, que é frequentemente o gargalo em sistemas escaláveis.

Desafios da SBA

Apesar de suas muitas vantagens, a SBA não está isenta de desafios:

Complexidade: Introduz complexidade adicional relacionada à distribuição de dados, sincronização e tolerância a falhas, o que pode aumentar o custo de desenvolvimento e manutenção.
Consistência dos dados: Manter a consistência dos dados em nós distribuídos pode ser difícil. A SBA frequentemente se alinha com o Teorema CAP, priorizando Disponibilidade e Tolerância a Partições em detrimento da Consistência forte, levando a modelos de consistência eventual. Isso significa que as réplicas podem ficar fora de sincronia por um tempo, mas eventualmente se atualizarão. É crucial gerenciar cuidadosamente a possibilidade de perda de dados em caso de falhas.
Gerenciamento de concorrência: Acesso concorrente a dados compartilhados em sistemas SBA exige mecanismos robustos de controle de concorrência para evitar conflitos.
Latência de comunicação: A latência de comunicação entre nós distribuídos pode impactar o desempenho, exigindo estratégias de otimização como localidade de dados e caching.

SBA na Prática: O Papel da Grade de Dados em Memória (IMDG) com Hazelcast

O conceito de "espaço" na Arquitetura Baseada em Espaço encontra sua realização mais eficaz em uma Grade de Dados em Memória (IMDG). Uma IMDG é um conjunto de computadores em rede/cluster que agrupam sua RAM para permitir que as aplicações compartilhem dados em alta velocidade. Elas são projetadas para processamento de dados em velocidades extremamente altas e para construir aplicações em larga escala que precisam de mais RAM do que um único servidor pode oferecer.

O Hazelcast é um excelente exemplo de uma solução IMDG distribuída em memória. Ele suporta uma variedade de estruturas de dados como Map, Set, List, MultiMap, RingBuffer e HyperLogLog.

Como Hazelcast se encaixa na SBA:

"Espaço" como uma Camada de Dados Operacionais Rápida: No contexto da SBA, o Hazelcast atua como a camada de dados operacionais rápida (Fast Operational Data Layer), onde os dados são armazenados e processados em memória para latência ultra-baixa e alto throughput.
Sincronização Automática: Uma das grandes vantagens do Hazelcast é a capacidade de gerenciar automaticamente a sincronização entre o banco de dados de origem e o cache, aliviando o desenvolvedor da responsabilidade de propagar atualizações manualmente.
Alta Performance e Escalabilidade Elástica: Hazelcast é projetado para alto desempenho, com latências que variam de microssegundos a milissegundos, e pode atingir milhões de transações por segundo (TPS). Ele permite escalar de forma elástica e automática, adicionando ou removendo nós conforme a carga de trabalho muda.
Resiliência e Tempo de Atividade (Uptime): O Hazelcast oferece alta resiliência e a capacidade de operar continuamente (Always-On), sendo capaz de garantir 99.999% de tempo de atividade em arquiteturas com replicação cross-cluster geográfica.
Ampla Variedade de Casos de Uso: Hazelcast é ideal para:
- Processamento de transações de aplicações *multicloud*, como detecção de fraudes em tempo real e processamento de pagamentos.
- Modernização de infraestruturas multicloud para *mainframe*, otimizando o desempenho e reduzindo custos.
- Sistemas de e-commerce e experiência do cliente omni-channel, fornecendo visibilidade de inventário em tempo real e alta capacidade de resposta em picos de demanda.
- Aplicações de IoT/IIoT e *Edge Computing, processando fluxos de dados massivos na borda para *insights em tempo real.
- Sistemas de trading financeiro, suportando processamento de transações de alto throughput e comunicação de baixa latência.
- Jogos online, onde a baixa latência e a capacidade de acomodar populações flutuantes de jogadores são cruciais.

O Hazelcast IMDG permite que os microsserviços armazenem o resultado de cada tarefa na grade, funcionando como um event bus clusterizado e um data store de baixa latência. Isso, juntamente com a capacidade de implantar modelos de Machine Learning gerenciados pelo cluster Hazelcast, o torna uma plataforma de computação operacional em memória completa e poderosa.

Conclusão

A Arquitetura Baseada em Espaço, impulsionada por soluções como o Hazelcast, oferece uma maneira eficaz de construir sistemas que exigem alta escalabilidade, autonomia, resiliência e desempenho. Ao aproveitar a velocidade das grades de dados em memória e a independência das unidades de processamento, as empresas podem lidar com cargas de trabalho massivas, processar dados em tempo real e garantir a continuidade dos negócios em ambientes distribuídos, desde a borda até a nuvem híbrida.

Embora introduza alguma complexidade no design e na gestão da consistência, os benefícios de um sistema que pode se adaptar dinamicamente ao crescimento e a falhas são inegáveis para as exigências do mundo digital atual. A SBA é, portanto, uma ferramenta valiosa no arsenal de qualquer arquiteto de software que busca construir sistemas de alto desempenho.

Bloom Filters: Variações e Casos de Uso Reais

Davi Orlandi — Tue, 24 Jun 2025 15:14:56 +0000

Você já precisou verificar rapidamente se um elemento pertence a um conjunto gigantesco, sem gastar muita memória? Ou já quis evitar consultas desnecessárias ao banco de dados, acelerando seu sistema? Se sim, está na hora de conhecer (ou aprofundar) o uso dos Bloom Filters.

Neste artigo, vou explicar o que são Bloom Filters, suas principais variações, mostrar exemplos de empresas que usam essa estrutura e apresentar casos de uso reais para inspirar sua próxima solução.

O que é um Bloom Filter?

Um Bloom Filter é uma estrutura de dados probabilística criada por Burton Howard Bloom em 1970. Ele serve para testar se um elemento pertence a um conjunto, com uma característica interessante: pode haver falsos positivos (dizer que um elemento está no conjunto quando não está), mas nunca falsos negativos (nunca diz que um elemento não está se ele realmente está).

Como funciona?

O Bloom Filter utiliza um array de bits de tamanho fixo e múltiplas funções hash. Para adicionar um elemento, ele é processado por todas as funções hash, e os bits correspondentes no array são marcados como 1. Para verificar se um elemento está presente, basta checar se todos os bits nas posições indicadas pelas funções hash estão em 1. Se algum estiver em 0, o elemento definitivamente não está no conjunto.

Principais características

Eficiência espacial: ocupa pouca memória, mesmo para conjuntos enormes.
Probabilístico: permite falsos positivos, mas nunca falsos negativos.
Operações rápidas: inserção e consulta em tempo constante.
Tamanho fixo: o array de bits não cresce após a criação.

Sobre a taxa de falsos positivos

A taxa de falsos positivos depende de alguns fatores: o tamanho do filtro (quantos bits ele tem), o número de funções hash que você usa e quantos elementos você adiciona ao filtro.

Tamanho do filtro: Quanto maior o filtro (mais bits), menor a probabilidade de falsos positivos. Um filtro maior tem mais espaço para distribuir os elementos, reduzindo a chance de colisões.
Número de funções hash: Usar mais funções hash pode reduzir a taxa de falsos positivos até certo ponto. No entanto, usar funções hash demais pode sobrecarregar o filtro e aumentar a taxa de falsos positivos novamente.
Número de elementos: Quanto mais elementos você adiciona ao filtro, maior a probabilidade de falsos positivos. Isso ocorre porque mais elementos significam mais bits sendo ativados, aumentando a chance de que uma consulta aleatória encontre todos os bits necessários ativados, mesmo que o elemento não esteja realmente no conjunto.

Variações e Evoluções

Com o tempo, surgiram variações para superar limitações do Bloom Filter tradicional:

Counting Bloom Filter: Permite remoção de elementos, usando contadores em vez de bits.
Scalable Bloom Filter: Cresce dinamicamente para suportar conjuntos de tamanho desconhecido, mantendo a taxa de falsos positivos sob controle.
Cuckoo Filter: Usa a técnica de hashing cuckoo, permite remoção eficiente e tem taxa de falsos positivos ainda menor.
Compressed Bloom Filter: Otimizado para transmissão de dados em redes, reduzindo o uso de banda.

Cada variação atende a cenários específicos, como necessidade de remoção, escalabilidade ou transmissão eficiente.

Empresas que usam Bloom Filters

Bloom Filters não são apenas teoria – grandes empresas usam essa estrutura em produção:

Microsoft (Azure Databricks): Otimiza consultas em grandes volumes de dados, descartando rapidamente dados irrelevantes.
Google Chrome: Verifica localmente se URLs são maliciosas, reduzindo o tráfego de rede e acelerando a navegação.
Facebook e Redis: Evitam consultas desnecessárias ao banco de dados, melhorando a performance de sistemas de cache.
Bancos e fintechs: Validam rapidamente CPFs ou identificadores em listas de fraude, acelerando transações e reduzindo custos.

Casos de Uso Reais

Veja alguns cenários práticos onde Bloom Filters brilham:

Filtragem de URLs maliciosas: Navegadores usam Bloom Filters para checar se um site é perigoso antes de consultar servidores remotos.
Validação de cupons: E-commerces verificam se um cupom já foi usado sem precisar de listas gigantescas em memória.
Cache em sistemas distribuídos: Antes de buscar um item no banco, verifica-se no Bloom Filter se ele pode estar no cache.
Controle de mensagens processadas: Sistemas de filas rastreiam mensagens já processadas, evitando retrabalho.
Validação de senhas comuns: Serviços de autenticação checam se uma senha está em uma lista de senhas fracas sem armazenar a lista completa.

Limitações e Cuidados

Apesar das vantagens, Bloom Filters têm limitações:

Falsos positivos: Não são indicados para cenários que exigem precisão absoluta.
Imutabilidade: O filtro tradicional não permite remoção de elementos (a não ser com variações como Counting Bloom Filter).
Tamanho fixo: É preciso estimar o tamanho do conjunto e a taxa de falsos positivos desejada antes de criar o filtro.

Conclusão

Bloom Filters são ferramentas poderosas para desenvolvedores que precisam de verificações rápidas e eficientes em grandes conjuntos de dados. Seja para otimizar caches, proteger usuários ou acelerar sistemas, essa estrutura pode ser o diferencial de performance que seu projeto precisa.

Se você ainda não usou Bloom Filters, experimente! E se já usa, compartilhe nos comentários como eles ajudaram no seu projeto.

Referências e Leitura Recomendada

Curtiu o artigo? Deixe seu feedback ou dúvidas nos comentários! 🚀

Progressive JSON em TypeScript: Carregando e Processando Dados de Forma Incremental

Davi Orlandi — Tue, 24 Jun 2025 15:10:12 +0000

A partir da necessidade de lidar com grandes volumes de dados e melhorar a experiência do usuário, surgiu a abordagem do Progressive JSON. Inspirada no conceito de imagens progressivas, essa técnica permite transmitir e processar dados JSON em fragmentos, fazendo com que partes importantes da informação sejam exibidas antes do recebimento completo do arquivo. Neste artigo, será apresentada uma visão detalhada do Progressive JSON, com exemplos práticos em TypeScript e orientações para sua implementação tanto no cliente quanto no servidor.

O Conceito de Progressive JSON

O Progressive JSON pode ser comparado a um Progressive JPEG, onde as informações são carregadas em “camadas”. Em vez de enviar um JSON completo de uma só vez, o servidor distribui os dados em chunks (pedaços) que possibilitam ao cliente iniciar o processamento e renderização imediatamente. Essa abordagem reduz a latência percebida e melhora a responsividade, especialmente em cenários como dashboards dinâmicos, redes sociais e aplicações de e-commerce.

Imagine, por exemplo, uma API que retorna um arquivo JSON grande contendo metadados, conteúdo do artigo e comentários de usuários. Com o carregamento progressivo, o cabeçalho e o corpo principal podem ser renderizados imediatamente, enquanto os comentários ou outros dados secundários são carregados posteriormente.

Cenários de Uso

Em aplicações modernas, o Progressive JSON se aplica a diversas situações, como:

Dashboards e sistemas de monitoramento, em que dados críticos são exibidos instantaneamente e os detalhes são carregados em background.
Redes sociais, onde posts e textos principais são renderizados imediatamente e dados adicionais, como comentários e reações, são carregados progressivamente.
E-commerces, que podem exibir as informações básicas do produto primeiro e carregar avaliações ou recomendações posteriormente.
Sistemas de conteúdo, permitindo que o texto principal do artigo seja exibido sem esperar por imagens de alta resolução ou conteúdos multimídia adicionais.

Essa abordagem não só aprimora a experiência final do usuário, mas também distribui melhor a carga no lado do cliente e do servidor, especialmente quando os dados totais são extensos.

Funcionamento: Enviando e Consumindo Dados em Fragmentos

No envio de um Progressive JSON, o servidor utiliza mecanismos como “Transfer-Encoding: chunked” para enviar os dados em partes. Cada fragmento pode ser um JSON parcial ou conter placeholders que serão substituídos progressivamente à medida que novos dados chegam.

No lado do cliente, o uso de streams possibilita a leitura incremental dos dados. Ao utilizar APIs como Fetch com suporte a ReadableStream, o cliente pode decodificar cada chunk recebido e processar os dados conforme chegam.

Considere o exemplo a seguir, que ilustra um cliente TypeScript lendo Progressive JSON a partir de um endpoint:

class ProgressiveJSONClient {
  async fetchProgressive(url: string, onProgress: (data: any) => void): Promise<any> {
    const response = await fetch(url);
    const reader = response.body?.getReader();
    const decoder = new TextDecoder();
    let buffer = '';

    if (!reader) throw new Error("Stream não disponível");

    while (true) {
      const { done, value } = await reader.read();
      if (done) break;

      buffer += decoder.decode(value, { stream: true });
      const lines = buffer.split('\n');
      buffer = lines.pop() || ''; // Preserva dados incompletos

      for (const line of lines) {
        if (line.trim()) {
          try {
            const data = JSON.parse(line);
            onProgress(data);
          } catch (e) {
            console.error("Erro no parsing do trecho:", e);
          }
        }
      }
    }

    // Processa o que sobrou no buffer
    if (buffer.trim()) {
      try {
        return JSON.parse(buffer);
      } catch (e) {
        console.error("Erro final de parsing:", e);
        return null;
      }
    }
  }
}

No código acima, cada linha recebida do stream é decodificada e processada. O método “onProgress” é chamado para cada objeto JSON completo, permitindo que a interface seja atualizada de maneira incremental.

Exemplo de Implementação no Servidor com Node.js

Para enviar um Progressive JSON, o servidor pode utilizar o Express e configurar os headers adequados. No exemplo a seguir, o servidor envia os dados em três fragmentos, simulando um cenário real de carregamento progressivo:

const express = require('express');
const app = express();

app.get('/api/progressive', (req, res) => {
  res.setHeader('Content-Type', 'application/json');
  res.setHeader('Transfer-Encoding', 'chunked');

  // Primeiro chunk: Conteúdo inicial com placeholders
  res.write(JSON.stringify({ header: "$1", content: "$2" }) + '\n');

  // Simulação de delay para enviar dados progressivamente
  setTimeout(() => {
    res.write('/* $1 */ "Bem-vindo ao blog"\n');
    res.write('/* $2 */ { "text": "Este é o conteúdo do artigo", "comments": "$3" }\n');

    setTimeout(() => {
      res.write('/* $3 */ ["Comentário 1", "Comentário 2"]\n');
      res.end();
    }, 1000);
  }, 500);
});

app.listen(3000, () => console.log('Servidor rodando na porta 3000'));

Nesse exemplo, o servidor inicia enviando um JSON com placeholders. Em seguida, com delays simulados, substitui esses placeholders pelos dados reais, possibilitando que o cliente comece a renderizar o cabeçalho e o conteúdo principal sem precisar esperar a finalização completa do envio.

Bibliotecas e Ferramentas para Parsing Progressivo

Para aplicações que exigem o processamento eficiente de grandes volumes de dados JSON, diversas bibliotecas podem facilitar o trabalho. Algumas das mais populares incluem:

stream-json

Projetada especificamente para processar grandes arquivos JSON em streams, a biblioteca stream-json permite a leitura e manipulação incremental dos dados. Ela é ideal para situações em que o JSON é grande demais para ser carregado integralmente na memória.

Exemplo de uso com stream-json:

import { parser } from 'stream-json';
import { streamValues } from 'stream-json/streamers/StreamValues';
import * as fs from 'fs';

const pipeline = fs.createReadStream('large-file.json')
  .pipe(parser())
  .pipe(streamValues());

pipeline.on('data', ({ value }) => {
  console.log('Valor lido:', value);
});

pipeline.on('end', () => {
  console.log('Processamento concluído.');
});

JSONStream

JSONStream é uma biblioteca leve que permite filtrar e transformar dados JSON em tempo real. Ela facilita a propagação de dados para sistemas que trabalham com streams.

Exemplo de uso com JSONStream (em TypeScript ou JavaScript):

import * as JSONStream from 'JSONStream';
import * as fs from 'fs';

const stream = fs.createReadStream('large-file.json')
  .pipe(JSONStream.parse('items.*'));

stream.on('data', (data) => {
  console.log('Item:', data);
});

stream.on('end', () => {
  console.log('Processamento do JSON concluído.');
});

fast-json-parse e jsonparse

Essas bibliotecas oferecem parsing de JSON de forma rápida e com tratamento de erros aprimorado. Enquanto fast-json-parse foca em desempenho e segurança – inclusive com validação de esquemas – o jsonparse é minimalista e útil para parsing baseado em eventos, permitindo tratar dados conforme eles chegam.

Exemplo simples com fast-json-parse:

import { parse } from 'fast-json-parse';

const jsonString = '{"name": "John", "age": 30}';
const result = parse(jsonString);

if (result.err) {
  console.error('Erro no parsing:', result.err);
} else {
  console.log('JSON parseado:', result.value);
}

Essas ferramentas possibilitam a criação de pipelines de dados robustos, diminuindo o uso de memória e o tempo de resposta, o que é fundamental para aplicações em tempo real.

Melhores Práticas no Uso de Progressive JSON

Para garantir que a implementação do Progressive JSON seja eficiente e segura, é importante adotar algumas boas práticas:

Utilizar streams para o processamento de arquivos ou fluxos de dados grandes, evitando o carregamento completo em memória.
Validar o JSON recebido, principalmente quando há fontes externas ou dados não confiáveis. Ferramentas como AJV podem ser integradas para validar esquemas.
Definir interfaces e tipos no TypeScript para assegurar a integridade dos dados e evitar erros de tipagem.
Implementar tratamento robusto de erros, envolvendo operações de parsing com blocos try-catch para capturar e lidar com exceções.
Garantir que tanto o servidor quanto o cliente tenham mecanismos para lidar com dados incompletos ou corrompidos. O uso de placeholders e identificadores de fragmentos pode simplificar a reconciliação dos dados.

Considerações Finais

O Progressive JSON representa uma técnica valiosa para aplicações modernas, onde a experiência do usuário e a performance são prioridades. Ao transmitir dados em fragmentos, é possível renderizar partes críticas da interface sem esperar pelo carregamento completo, resultando numa sensação de maior agilidade e reatividade.

A implementação dessa abordagem em projetos TypeScript/Node.js é facilitada pelas diversas bibliotecas e ferramentas disponíveis, como stream-json e JSONStream. Além disso, a adoção de melhores práticas – como a validação dos dados e o tratamento de erros – garante que a aplicação permaneça robusta mesmo sob alto volume de dados.

O Progressive JSON pode ser a solução ideal em cenários onde a latência e o desempenho são desafios críticos. Se você trabalha com dashboards dinâmicos, aplicações em tempo real ou qualquer sistema que lida com grandes quantidades de dados, vale a pena experimentar essa abordagem e ajustar seu fluxo de dados para oferecer uma experiência aprimorada aos usuários.

Curtiu o conteúdo? Deixe seus comentários, compartilhe suas experiências e explore ainda mais esse recurso para otimizar suas aplicações!

Entendendo Back Pressure: O Semáforo dos Seus Sistemas Distribuídos

Davi Orlandi — Fri, 20 Jun 2025 18:45:25 +0000

Seu sistema está lento, travando sob carga ou apresentando falhas em cascata? Um dos culpados pode ser a ausência de um mecanismo crucial: Back Pressure.

Em sistemas distribuídos, componentes se comunicam constantemente. Um producer (upstream) envia dados para um consumer (downstream) processar. Mas o que acontece quando o producer é muito mais rápido que o consumer? O consumer fica sobrecarregado, sua fila de processamento explode, a memória estoura e o sistema inteiro pode cair.

É aqui que entra o Back Pressure.

O que é Back Pressure?

Back Pressure é um mecanismo de feedback que permite ao componente consumer (sobrecarregado) sinalizar ao producer (rápido demais) para que ele diminua o ritmo ou pare de enviar dados temporariamente.

Pense nisso como um controle de tráfego. Em vez de deixar os dados fluírem sem controle e causarem um congestionamento, o sistema se autorregula para garantir um fluxo suave e estável.

A Analogia do Rio e da Barragem

Para entender de forma intuitiva, imagine um rio (fluxo de dados) e uma barragem (consumer).

Em um fluxo normal, a barragem mantém suas comportas abertas, permitindo que a água passe. Se chuvas intensas aumentam drasticamente o volume do rio, a barragem começa a fechar suas comportas. Essa resistência criada é a back pressure. A barragem força o rio a desacelerar, evitando uma inundação na área abaixo dela. Assim que o nível da água se estabiliza, as comportas podem ser abertas novamente.

Nossos sistemas funcionam da mesma forma: aplicamos resistência (back pressure) para sinalizar que o fluxo precisa ser reduzido, evitando que o serviço a jusante seja "inundado".

Como Funciona na Prática?

A implementação de back pressure geralmente envolve alguns conceitos-chave:

Loop de Feedback: O consumer monitora sua própria capacidade (CPU, memória, tamanho da fila). Ao se aproximar do limite, ele envia um sinal "desacelere!" para o producer.
Controle de Fluxo: Protocolos como o TCP já possuem mecanismos de controle de fluxo nativos. Em nível de aplicação, podemos usar algoritmos como Leaky Bucket ou Token Bucket para limitar a taxa de processamento.
Gerenciamento de Buffers: Em vez de buffers ilimitados que podem causar OutOfMemoryError, sistemas com back pressure usam buffers limitados ou ajustáveis, que, quando cheios, ativam o sinal de feedback.
Processamento Assíncrono: Frameworks reativos modernos implementam back pressure de forma assíncrona e não-bloqueante, o que é fundamental para a eficiência de recursos.

Por Que Back Pressure é Essencial?

Ignorar o back pressure é uma receita para o desastre em sistemas de alta carga. Implementá-lo corretamente traz benefícios diretos:

Previne Sobrecarga e Falhas: É a principal linha de defesa contra o efeito dominó, onde a falha de um componente derruba outros em sequência.
Aumenta a Estabilidade: O sistema se torna mais previsível e resiliente, operando dentro de limites seguros.
Otimiza Recursos: Evita o desperdício de CPU e memória com tentativas de processar uma carga impossível, liberando recursos para operar de forma eficiente.
Reduz a Perda de Dados: Ao evitar que buffers estourem, garante que os dados enviados sejam de fato processados.

Back Pressure em Ação: Akka Streams

Um excelente exemplo prático é o Akka Streams, um dos membros fundadores da especificação Reactive Streams.

Em Akka Streams, a comunicação entre os estágios de um fluxo (os operators) é feita por mensagens assíncronas. Um consumer solicita ao producer um número exato de elementos que ele consegue processar (ex: request(16)). O producer envia no máximo essa quantidade e depois para, aguardando um novo pedido.

O ponto principal é que essa espera é non-blocking. O thread do producer não fica parado esperando; ele é liberado para um pool de threads e pode ser usado para outras tarefas. Essa é uma abordagem extremamente eficiente e amigável aos recursos do sistema.

Reflexão

Ao projetar seu próximo serviço, pergunte-se: "O que acontece se o serviço do qual dependo ficar lento? E o que acontece se meu serviço ficar mais rápido que seus consumidores?". Se a resposta envolver falhas, é hora de implementar uma estratégia de back pressure.

Entendendo Outbox Pattern

Davi Orlandi — Tue, 10 Jun 2025 19:00:58 +0000

O que é o Outbox Pattern?

O Outbox Pattern é um padrão arquitetural que garante a consistência entre operações de banco de dados e a publicação de eventos em sistemas distribuídos. O nome "Outbox" não é à toa: a ideia central desse padrão é registrar eventos de domínio em uma tabela especial (a outbox), deixando para um componente externo — chamado de Outbox Publisher — a responsabilidade de processar e publicar esses eventos para outros sistemas.

Por que o Outbox Pattern é necessário?

Imagine um cenário em que temos uma ordem de pedido, que pode ser confirmada ou cancelada. Quando um pedido é confirmado ou cancelado, normalmente precisamos não só atualizar o banco de dados, mas também avisar outros sistemas — por exemplo, para atualizar o estoque, enviar e-mails ou notificar o financeiro. Surge então um problema clássico: como garantir que, se o banco de dados foi atualizado, o evento também será publicado? E se a publicação do evento falhar depois que o pedido já foi confirmado no banco?

Como o Outbox Pattern funciona na prática?

É aí que entra o Outbox Pattern. Em vez de tentar atualizar o banco e publicar o evento ao mesmo tempo (correndo o risco de uma das operações falhar), fazemos tudo em uma única transação: salvamos o pedido e registramos o evento na tabela de outbox. Essa tabela funciona como uma fila local de eventos que precisam ser processados. Nada é enviado para fora ainda.

Exemplo prático de uso

Por exemplo, ao confirmar um pedido, você faz algo assim:

Atualiza o status do pedido para "CONFIRMADO" no banco de dados.
Cria um registro na tabela de outbox, dizendo: "Pedido X foi confirmado".

Tudo isso acontece dentro da mesma transação. Se der erro, nada é salvo. Se der certo, tanto o pedido quanto o evento ficam registrados de forma atômica.

Exemplo de registro na tabela de outbox

Para ilustrar, imagine que o registro na tabela de outbox poderia ter o seguinte formato JSON:

{
  "id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "pedido-123",
  "aggregate_type": "pedido",
  "type": "PedidoConfirmado",
  "payload": {
    "pedido_id": "pedido-123",
    "cliente_id": "cliente-456",
    "data_confirmacao": "2024-06-10T10:00:00Z"
  },
  "status": "pending",
  "created_at": "2024-06-10T09:59:59Z"
}

Nesse exemplo, o payload contém os dados específicos do evento, como o ID do pedido, o ID do cliente e a data de confirmação.

O papel do Outbox Publisher

Depois, entra em cena o Outbox Publisher. Ele é um processo separado, que fica monitorando a tabela de outbox. Periodicamente, ele busca os eventos pendentes, publica cada um deles para um message broker (como Kafka, RabbitMQ, SQS, etc.) e, só então, marca o evento como processado. Se a publicação falhar, o evento permanece na tabela e será tentado novamente depois, garantindo que nada se perca.

Exemplo de evento processado

Após a publicação bem-sucedida, o status do evento na tabela de outbox é atualizado:

{
  "id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "pedido-123",
  "aggregate_type": "pedido",
  "type": "PedidoConfirmado",
  "payload": {
    "pedido_id": "pedido-123",
    "cliente_id": "cliente-456",
    "data_confirmacao": "2024-06-10T10:00:00Z"
  },
  "status": "processed",
  "created_at": "2024-06-10T09:59:59Z",
  "processed_at": "2024-06-10T10:00:01Z"
}

O campo status agora é "processed", e o campo processed_at indica quando o evento foi publicado.

Se a publicação falhar, o evento pode ser retentado um número limitado de vezes antes de ser movido para uma "dead letter queue" para análise posterior.

Vantagens do Outbox Pattern

Consistência garantida: O pedido só é confirmado se o evento também for registrado, evitando inconsistências entre o banco de dados e os sistemas externos.
Resiliência: Se o broker estiver fora do ar, os eventos ficam guardados na tabela de outbox e serão enviados assim que possível, sem perda de informação.
Desacoplamento: O serviço de pedidos não precisa saber quem vai consumir o evento. Ele só registra o que aconteceu, e o Outbox Publisher cuida do resto.
Escalabilidade e observabilidade: É possível monitorar, reprocessar ou até mesmo auditar eventos que ficaram pendentes ou falharam, facilitando a manutenção e a evolução do sistema.

Conclusão

No fim das contas, o Outbox Pattern é uma forma elegante e robusta de garantir que nada se perde no caminho entre o banco de dados e o mundo externo, mesmo em cenários de falha. Ele é amplamente utilizado em sistemas modernos, principalmente quando você precisa de confiabilidade, rastreabilidade e consistência em ambientes distribuídos.

Desvendando Event-Driven Architecture e Mensageria em Go com Watermill

Davi Orlandi — Thu, 29 May 2025 18:34:36 +0000

O que é o Watermill?

O Watermill é uma biblioteca open-source para Go, criada para facilitar o desenvolvimento de aplicações baseadas em eventos e mensagens. Ele abstrai a complexidade dos principais brokers do mercado (Kafka, RabbitMQ, NATS, Google Pub/Sub, Redis Streams, entre outros), oferecendo uma API unificada, simples e extensível. Com o Watermill, você pode construir pipelines de mensagens robustos, escaláveis e resilientes, sem se preocupar com os detalhes de cada sistema de mensageria.

Por que usar Watermill?

Sistemas baseados em eventos trazem vantagens como desacoplamento, escalabilidade horizontal e facilidade para implementar padrões como CQRS e Event Sourcing. O Watermill resolve problemas comuns desse tipo de arquitetura, como:

Abstração dos brokers: troque Kafka por RabbitMQ (ou vice-versa) sem reescrever sua lógica.
Middleware plugável: adicione logging, retries, métricas e outras funcionalidades de forma simples.
Performance: processa centenas de milhares de mensagens por segundo, aproveitando o modelo concorrente do Go.
Testabilidade: suporte a brokers em memória para testes locais rápidos.

Principais Componentes do Watermill

O Watermill é construído em torno de quatro conceitos principais:

Publisher: responsável por publicar mensagens em um tópico.
Subscriber: consome mensagens de um tópico.
Router: roteia mensagens entre publishers e subscribers, aplicando middlewares e handlers.
Middleware: adiciona funcionalidades transversais, como logging, retries, limitação de taxa, etc.

Esses componentes se conectam de forma flexível, permitindo criar desde fluxos simples até pipelines complexos de processamento de eventos.

Protocolos e Brokers Suportados

O Watermill suporta, de forma oficial, os principais sistemas de mensageria do mercado:

Kafka
RabbitMQ (AMQP)
Google Cloud Pub/Sub
AWS SNS/SQS
Redis Streams
SQL (PostgreSQL, MySQL)
GoChannel (in-memory, ótimo para testes)
HTTP

Isso significa que você pode começar com um broker simples e migrar para algo mais robusto conforme sua aplicação cresce, sem grandes mudanças no código.

Exemplo Prático: Publicando e Consumindo Mensagens com Kafka

Vamos ver um exemplo básico de como publicar e consumir mensagens usando Watermill com Kafka. O mesmo padrão vale para outros brokers, mudando apenas a configuração.

Pré-requisitos:

Go instalado
Docker rodando Kafka localmente (veja docker-compose aqui)
Dependências instaladas:

  go get github.com/ThreeDotsLabs/watermill
  go get github.com/ThreeDotsLabs/watermill-kafka/v3

Publisher:

package main

import (
    "github.com/ThreeDotsLabs/watermill"
    "github.com/ThreeDotsLabs/watermill-kafka/v3/pkg/kafka"
    "github.com/ThreeDotsLabs/watermill/message"
    "log"
)

func main() {
    logger := watermill.NewStdLogger(false, false)
    publisher, err := kafka.NewPublisher(
        kafka.PublisherConfig{
            Brokers:   []string{"localhost:9092"},
            Marshaler: kafka.DefaultMarshaler{},
        },
        logger,
    )
    if err != nil {
        log.Fatal(err)
    }

    msg := message.NewMessage(watermill.NewUUID(), []byte("Olá, Watermill!"))
    if err := publisher.Publish("exemplo.topico", msg); err != nil {
        log.Fatal(err)
    }
    log.Println("Mensagem publicada!")
}

Subscriber:

package main

import (
    "context"
    "github.com/ThreeDotsLabs/watermill"
    "github.com/ThreeDotsLabs/watermill-kafka/v3/pkg/kafka"
    "github.com/ThreeDotsLabs/watermill/message"
    "log"
)

func main() {
    logger := watermill.NewStdLogger(false, false)
    subscriber, err := kafka.NewSubscriber(
        kafka.SubscriberConfig{
            Brokers:       []string{"localhost:9092"},
            Unmarshaler:   kafka.DefaultMarshaler{},
            ConsumerGroup: "exemplo-grupo",
        },
        logger,
    )
    if err != nil {
        log.Fatal(err)
    }

    messages, err := subscriber.Subscribe(context.Background(), "exemplo.topico")
    if err != nil {
        log.Fatal(err)
    }

    for msg := range messages {
        log.Printf("Mensagem recebida: %s", string(msg.Payload))
        msg.Ack()
    }
}

Dica:

Para testar localmente, rode o Kafka com Docker, execute o subscriber e depois o publisher. Você verá as mensagens fluindo entre eles.

Casos de Uso e Vantagens

O Watermill é ideal para:

Microsserviços que precisam se comunicar de forma assíncrona e desacoplada.
Sistemas de processamento de eventos em tempo real (monitoramento, analytics, notificações).
Implementação de padrões como CQRS e Event Sourcing.
Projetos que exigem escalabilidade horizontal e resiliência.

Entre as vantagens, destacam-se a flexibilidade (suporte a múltiplos brokers), performance, API intuitiva e facilidade de integração com middlewares e métricas (Prometheus).

Conclusão

O Watermill é uma excelente escolha para quem quer adotar event-driven architecture e mensageria em Go. Ele abstrai a complexidade dos brokers, oferece uma API poderosa e flexível, e permite construir sistemas modernos, escaláveis e resilientes. Se você quer dar o próximo passo na arquitetura do seu projeto Go, vale muito a pena experimentar o Watermill.

Links úteis:

Se ficou com dúvidas ou quer compartilhar sua experiência com Watermill, deixe um comentário!

Tipagem segura e Eficiência com next-safe-action no Next.js

Davi Orlandi — Fri, 07 Mar 2025 02:14:36 +0000

Segurança e Eficiência com `next-safe-action` no Next.js

O next-safe-action é uma biblioteca poderosa para fortalecer a segurança e eficiência das Server Actions no Next.js, garantindo tipagem consistente e validação robusta para aplicações que utilizam o App Router.

📌 O que é o `next-safe-action`?

Essa biblioteca foi criada para evitar problemas comuns ao trabalhar com Server Actions, como dados não validados, erros silenciosos e tipagem inconsistente entre o backend e o frontend.

🔥 Principais Benefícios:

✅ API simples e intuitiva – fácil de integrar e usar.

✅ Segurança de tipos de ponta a ponta – evita erros de tipagem na comunicação entre cliente e servidor.

✅ Validação com Zod e outras bibliotecas – garante que apenas dados corretos sejam processados.

✅ Suporte a formulários (Form Actions) – facilita a submissão e tratamento de formulários.

✅ Middleware para autenticação e logs – permite adicionar camadas de segurança adicionais.

✅ Tratamento avançado de erros – fornece um fluxo estruturado para capturar erros e notificá-los corretamente.

✅ Otimizações na UI (atualizações otimistas) – melhora a experiência do usuário ao refletir mudanças instantaneamente.

🚀 Como Usar o `next-safe-action` no Next.js

1️⃣ Instalando a Biblioteca

Se você usa Zod para validação (recomendado), instale os pacotes necessários:

npm install next-safe-action zod

2️⃣ Criando um Cliente de Ação

No seu projeto, crie um cliente para centralizar as Server Actions.

// lib/safe-action.ts
import { createSafeActionClient } from 'next-safe-action';

export const actionClient = createSafeActionClient();

3️⃣ Definindo uma Server Action com Validação

Aqui criamos uma ação que atualiza um usuário, garantindo que os dados estejam corretos antes do processamento.

'use server';

import { z } from 'zod';
import { actionClient } from '@/lib/safe-action';

const UserSchema = z.object({
  id: z.string(),
  name: z.string().min(2, 'Nome muito curto'),
  email: z.string().email('E-mail inválido'),
});

export const updateUserAction = actionClient
  .schema(UserSchema)
  .action(async ({ parsedInput }) => {
    const { id, name, email } = parsedInput;

    // Simulando uma atualização no banco
    console.log(`Atualizando usuário ${id}: ${name} (${email})`);

    return { message: 'Usuário atualizado com sucesso!' };
  });

4️⃣ Consumindo a Server Action no Frontend

Agora, utilizamos essa ação em um formulário React.

'use client';

import { useAction } from 'next-safe-action';
import { updateUserAction } from '@/actions/user-actions';

function UserForm() {
  const { execute, result } = useAction(updateUserAction);

  const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    const formData = new FormData(event.currentTarget);
    await execute(Object.fromEntries(formData));
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="id" type="text" placeholder="ID do usuário" required />
      <input name="name" type="text" placeholder="Nome" required />
      <input name="email" type="email" placeholder="E-mail" required />
      <button type="submit">Atualizar</button>
      {result?.data && <p>{result.data.message}</p>}
      {result?.validationErrors && (
        <ul>
          {Object.entries(result.validationErrors).map(([field, errors]) => (
            <li key={field}>{`${field}: ${errors.join(', ')}`}</li>
          ))}
        </ul>
      )}
    </form>
  );
}

💡 Conclusão

O next-safe-action facilita o uso seguro e eficiente das Server Actions no Next.js, garantindo tipagem forte, validação confiável e experiência do usuário aprimorada. Se você está construindo aplicações modernas, essa biblioteca é uma excelente adição ao seu stack! 🚀

Understanding CQRS and Event Sourcing.

Davi Orlandi — Mon, 15 Jul 2024 18:04:14 +0000

Introduction

In modern software architecture, ensuring scalability, maintainability, and performance is crucial. Two patterns that help achieve these goals are CQRS (Command Query Responsibility Segregation) and Event Sourcing. This article explores these concepts, their benefits, and how they can be implemented.

What is CQRS?

CQRS stands for Command Query Responsibility Segregation. It is a pattern that separates read and write operations for a data store. Traditionally, CRUD (Create, Read, Update, Delete) operations are performed on a single model, which can lead to complexity and inefficiency, especially in large-scale systems.

Benefits of CQRS

Scalability: By separating reads and writes, each can be scaled independently.
Performance: Read models can be optimized for queries, and write models can be optimized for updates.
Simplified Models: Separation of concerns makes the codebase cleaner and easier to maintain.

Implementing CQRS

In a CQRS system, commands (writes) and queries (reads) are handled by different models:

Command Model: Handles state-changing operations (e.g., create, update, delete).
Query Model: Handles read-only operations (e.g., fetch data).

Here's a basic example using TypeScript:

// Command Model
class CreateUserCommand {
    constructor(public name: string, public email: string) {}
}

class UserCommandHandler {
    handle(command: CreateUserCommand): void {
        // Logic to handle user creation
        // e.g., save to database
    }
}

// Query Model
class UserQuery {
    constructor(public id: string) {}
}

class UserQueryHandler {
    handle(query: UserQuery): User | null {
        // Logic to fetch user data
        // e.g., retrieve from database
        return { id: query.id, name: "John Doe", email: "john.doe@example.com" };
    }
}

What is Event Sourcing?

Event Sourcing is a pattern where state changes are captured as a sequence of events. Instead of storing the current state, the system stores a series of events that describe state transitions.

Benefits of Event Sourcing

Auditability: Every change is recorded, providing a complete audit trail.
Event Replay: System state can be reconstructed by replaying events.
Decoupling: Events can be used to integrate with other systems asynchronously.

Implementing Event Sourcing

In an event-sourced system, state changes are represented as events:

// Event
class UserCreatedEvent {
    constructor(public id: string, public name: string, public email: string) {}
}

// Event Store
class EventStore {
    private events: Array<any> = [];

    save(event: any): void {
        this.events.push(event);
    }

    getEvents(): Array<any> {
        return this.events;
    }
}

// Aggregate
class User {
    private id: string;
    private name: string;
    private email: string;

    constructor(private eventStore: EventStore) {}

    create(id: string, name: string, email: string): void {
        const event = new UserCreatedEvent(id, name, email);
        this.apply(event);
        this.eventStore.save(event);
    }

    private apply(event: UserCreatedEvent): void {
        this.id = event.id;
        this.name = event.name;
        this.email = event.email;
    }
}

// Usage
const eventStore = new EventStore();
const user = new User(eventStore);
user.create("1", "John Doe", "john.doe@example.com");

console.log(eventStore.getEvents());

Combining CQRS and Event Sourcing

CQRS and Event Sourcing complement each other well. Event Sourcing naturally fits the write side of CQRS, where commands result in events that are stored and processed. The read side can use these events to build query models.

Example

// Command Model (Event Sourced)
class UserCommandHandler {
    constructor(private eventStore: EventStore) {}

    handle(command: CreateUserCommand): void {
        const event = new UserCreatedEvent(command.name, command.email);
        this.eventStore.save(event);
    }
}

// Query Model
class UserReadModel {
    private users: { [key: string]: User } = {};

    handleEvent(event: UserCreatedEvent): void {
        this.users[event.id] = new User(event.id, event.name, event.email);
    }

    getUser(id: string): User | null {
        return this.users[id] || null;
    }
}

// Usage
const eventStore = new EventStore();
const userCommandHandler = new UserCommandHandler(eventStore);
const userReadModel = new UserReadModel();

userCommandHandler.handle(new CreateUserCommand("John Doe", "john.doe@example.com"));
eventStore.getEvents().forEach(event => userReadModel.handleEvent(event));

console.log(userReadModel.getUser("1"));

Forem: Davi Orlandi

GO profiling using pprof

What is pprof?

How pprof works

Collecting profiles

Analyzing profiles

The Big Bad Boy

You can do the same for memory, block, mutex, and goroutine profiles

Visualization (Graphviz required)

Don’t spray and pray

ADDITIONAL: Profiling in Kubernetes

Useful Links & References

So, Thanks!

See you soon ;)

Getting Started With Linux

Base needed knowledge:

Whats is Linux?

A linux system is divided in three layers:

What is a Linux distribution?

Debian:

Package Management

Red Hat Enterprise Linux (RHEL)

Package Management

Ubuntu

Package Management

Fedora

Package Management

The shell

BASH (Bourne Again Shell)

Filesystem basics

Common directories

Paths

Permissions & users

Networking basics

Network concepts

Common networking commands:

Useful links & references

Thanks!

See you soon ;)

RAG with MongoDB Vector Search PART 1

What is RAG?

Why Vector Search Matters in RAG?

Let's think about it:

Why use MongoDB Atlas Vector Search?

How MongoDB Vector Search Works

Creating a Vector Search Index in MongoDB Atlas

Documentation

See you soon ;)

Como implementar um Ledger em sístemas distribuídos

O que é um ledger?

Como fazer?

Persistência e Concorrência

Lidando com Dinheiro em Sistemas Distribuídos

Por que usar int e não float?

Estrutura para Múltiplas Moedas

Aplicando o Lock Otimista e Transações

Como ficam meus dados?

ledgers

transactions

Considerações Finais

Arquitetura Baseada em Espaço (SBA - Space-Based Architecture)

Componentes Essenciais da SBA

Princípios da Arquitetura Baseada em Espaço

Vantagens da SBA

Desafios da SBA

SBA na Prática: O Papel da Grade de Dados em Memória (IMDG) com Hazelcast

Como Hazelcast se encaixa na SBA:

Conclusão

Bloom Filters: Variações e Casos de Uso Reais

O que é um Bloom Filter?

Como funciona?

Principais características

Sobre a taxa de falsos positivos

Variações e Evoluções

Empresas que usam Bloom Filters

Casos de Uso Reais

Limitações e Cuidados

Conclusão

Referências e Leitura Recomendada

Progressive JSON em TypeScript: Carregando e Processando Dados de Forma Incremental

Por que usar `int` e não `float`?

Segurança e Eficiência com `next-safe-action` no Next.js

📌 O que é o `next-safe-action`?

🚀 Como Usar o `next-safe-action` no Next.js