guilherme rodrigues · backend engineer · brazil

Distributed systems,
end to end.

I design, ship and operate event-driven systems in Go for banking and enterprise. That covers the API at the edge, the messaging in between, the data underneath, and the observability that tells you when any of it is lying.

01 / request

One event enters.

A financial event hits a spec-first Go API. The contract is OpenAPI and the server is generated from it, so the edge never drifts from the spec.

POST /events          202 Accepted · 3.1 ms
{
  "type":    "payment.authorized",
  "amount":  { "value": 1250.00, "currency": "BRL" },
  "account": "acc_7f3a…",
  "ts":      "2026-10-21T17:42:03Z"
}

02 / throughput

Then eight hundred a second.

Per pod. Validated, preprocessed and published to NATS under 50 ms at p99, while dispatchers downstream route each event where it belongs.

tps/pod  ▅▅▆▆▅▆▇▆▆▅▆▆▇▆▅▆▆▆▅▆  800
p99      ▂▂▃▂▂▂▃▂▂▂▂▃▂▂▂▂▃▂▂▂  31ms

03 / scale

Load grows. So does the system.

Stateless pods scale out horizontally. Underneath, a shared hexagonal data layer stays the single source of truth: 1TB+ a week in, reads under 40 ms.

17:42:05  hpa    scaled ingest 1 → 2
17:42:06  sched  ingest-1 ready
17:42:06  hpa    scaled ingest 2 → 3

04 / failure

Things break. It keeps going.

A pod dies mid-flight. Traffic reroutes, the scheduler brings it back, the queue absorbs the rest. Go ahead, click a pod and kill it.

+0.0s  pod ingest-1 killed
+0.0s  3 in-flight requests retried upstream
+2.4s  scheduler restarted ingest-1
+3.3s  ingest-1 ready
       pages sent: 0

05 / visibility

And every hop is visible.

Traces from the edge to the database. I've built that kind of observability platform from zero, and it's the first thing I add to any system I touch.

hover a span to inspect it

selected work

Case files.

01ingest-apic6 bank800+ TPS/pod · p99 < 50 ms

problem: Application events from across a bank needed one front door: fast, strict about contracts, and safe to scale.
design: Spec-first OpenAPI with a generated Go server (ogen). Preprocessing happens at the edge, then events are published to NATS so dispatchers can route them downstream independently.
outcome: 800+ TPS per pod at sub-50 ms p99, with a contract that can't drift from the implementation.

clients ──▶ ingest-api ──▶ nats ──────▶ dispatcher ──▶ mongodb
            openapi/ogen   jetstream     routing

02data-layerc6 bank1TB+/week · reads < 40 ms

problem: The ingest API and the dispatcher needed a single source of truth over MongoDB, with rich filtering on reads.
design: Hexagonal architecture with a codegen-heavy workflow that keeps contracts and implementation in sync. I benchmarked $facet aggregation against cursor-based pagination and picked the right one per access pattern.
outcome: 1TB+ ingested per week, reads under 40 ms with rich filters.

03log-volumec6 bank5TB/day → 1TB/day

problem: Production log volume became an incident of its own.
design: Helped diagnose it during incident response, then reclassified high-frequency logs from info to debug through live config, with no redeploy.
outcome: Production log volume dropped from 5TB to 1TB a day.

04pubsubdell technologiesreplaced kafka · 10+ months, zero downtime

problem: Manufacturing and logistics data needed to move in real time, but IT constraints ruled out Kafka.
design: A custom pub/sub system in Go built on channels and worker pools, handling 1M+ rows per request.
outcome: Ran for 10+ months without downtime and cut update latency from 2 minutes to under 10 seconds, which made real-time enterprise analytics possible.

producers ──▶ [ chan ] ──▶ worker pool ×N ──▶ subscribers
                                 1M+ rows/request

05otel-platformdell technologiesobservability, from zero

problem: Microservices, APIs and data pipelines with no shared view of what was happening in production.
design: A Go + OpenTelemetry platform built from the ground up, with tracing and monitoring across services, APIs and pipelines, surfaced in Grafana.
outcome: Proactive incident detection and full-stack visibility across the team's production systems.

06realtime-apidell technologies9,000+ records/pull · −95% update downtime

problem: Teams needed real-time access to large data sets without updates taking the service down.
design: A high-throughput REST API using a service-repository pattern in a cloud-native microservices setup.
outcome: 9,000+ records per pull, and update downtime cut by 95% to under 2 seconds.

07graph-goopen source~100 ★ on github

what: A zero-config Go tool that visualizes Docker architectures. Point it at your setup and get the graph.
where: github.com/guilherme-grimm/graph-go

about

I own the arrows, too.

Most engineers own a box in the diagram. I like owning what sits between the boxes as well: how a request crosses the edge, how events move between services, where the data lands, and how you'll know when something is wrong.

I've been doing that in production since 2022, across banking and enterprise manufacturing, mostly in Go. I care about spec-first APIs, codegen where it pays off, simple architecture and operational reliability.

The layers I own, with the tools and the evidence for each
edge	openapi · ogen · rest · go	800+ TPS/pod
transport	nats jetstream · sqs · in-house pub/sub	replaced kafka
storage	mongodb · postgres · spanner · sql server	1TB+/week
observe	opentelemetry · grafana	built from zero
ship	kubernetes · docker · gitlab ci · testcontainers	caught before staging

That's the work.
Want it on your system?

I take on consulting engagements: architecture reviews, scaling and reliability work, and observability from zero. Book a call, or just write.

30 min · deep dive 15 min · intro

Distributed systems,end to end.

One event enters.

Then eight hundred a second.

Load grows. So does the system.

Things break. It keeps going.

And every hop is visible.

That's the work.Want it on your system?

Distributed systems,
end to end.

That's the work.
Want it on your system?