Skip to content
STACK IT FIRST
Install the skills
03 · Backend · Scale · Product API

Go services + Postgres, Rust where latency is the product

Compiled, typed services with a generated contract each, boring infrastructure, and a compiler as the second reviewer.
Agent fit4/5 Scale · Run it for many Reviewed

The stack

Framework
Go with chi or Echo; Rust with Axum for the hot path
Runtime
Static binaries in containers
Data
Postgres per service via sqlc (Go) or sqlx (Rust), Redis or NATS between services
Auth
OIDC at the gateway, service-to-service mTLS or signed tokens
Hosting
Kubernetes or Nomad, a gateway in front
Also
  • OpenAPI or protobuf per service, generated clients
  • OpenTelemetry everywhere
  • Contract tests between services
AGENTS.md + real projects on STACK IT FAST (opens in a new tab)

Why agents do well here

4/5
  • Go's formatting and small language make agent-written code indistinguishable from the team's, which is what code review at this size depends on.
  • Generated contracts per service let the agent work inside one service and trust the rest.
  • The compiler and sqlc's typed queries catch the class of errors an agent introduces most in dynamic languages.

Avoid at this tier

  • A service per noun; a service per team boundary.
  • Rust everywhere for consistency; use it only where p99 latency is the product.
  • Sharing databases between services; share contracts and events.

How it fits together

At scale the product API is several services owned by several teams. Go is the default for its conventions and compile-time checks; Rust earns its place on the one or two paths where latency is the product. For those Rust services, the Rust + Axum + PostgreSQL rules give the agent the same compiler-first loop.

Folder layout

services/<name>/
  cmd/            main.go
  internal/       <domain>/ {handler, service, queries.sql, tests}
  api/            openapi.yaml or .proto, generated clients published
platform/         gateway, otel collector, shared CI

First five decisions

Lock these in before the agent writes the second feature. Each one removes a choice it would otherwise make differently every time.

  1. 01 A contract per service
  2. 02 Sqlc or sqlx for typed SQL
  3. 03 Events over shared tables
  4. 04 OpenTelemetry from the first commit
  5. 05 Contract tests in CI

When to move on

This is the top tier. From here the work is keeping the boundaries explicit, not changing the stack. The Backend Scale page lists what stays the same.

Same tier, other profiles