What a Go Engineer Learns Building Their First Real Python Service

Yogesh23012001 — Sun, 31 May 2026 16:18:04 +0000

I spent the last three years writing Go. At NPCI I built payment systems where the wrong defaults cost real money. At ShopUp I work on backend services that have to be right, fast, and observable in that order.

This weekend I built my first real Python service: an idempotent task queue with a Postgres-backed worker, retries, dead-letter queue, full Prometheus observability, and a 16-test suite. From mkdir to GitHub release in eight hours.

I want to write about what surprised me. Some of it was the language. Most of it wasn't.

What I built

The repo is here. The short version: an HTTP API that accepts tasks with an Idempotency-Key header (Stripe style), persists them to Postgres, and a separate async worker process that picks them up using SELECT ... FOR UPDATE SKIP LOCKED, runs them, and writes the outcome back.

Same key + same body returns the cached response. Same key + different body returns 422. Failed tasks retry up to max_attempts; tasks that exhaust the budget go to a DEAD_LETTER state for operator review.

This is the pattern most payment systems are built on. I've consumed it through Go libraries at NPCI; I'd never implemented it from scratch.

Benchmark on my MacBook Air M2: 590 req/s on GET /tasks at concurrency 50, p50 67ms, p99 228ms. The latency tail is dominated by Postgres connection-pool contention — pool size 10 versus 50 concurrent requests means 40 of them are waiting. That's not a Python problem; that's the same problem I'd have in any language with the same pool configuration. Production fix is PgBouncer or a larger pool.

What transferred from Go

More than I expected.
The mental model for state machines transferred cleanly. A task is PENDING, becomes PROCESSING when a worker claims it, ends as SUCCEEDED, FAILED, or DEAD_LETTER. The state guards are enforced in code the same way I'd enforce them in Go — return a 409 if someone tries an illegal transition. SQLAlchemy's enum type even maps to a Postgres task_status enum, so the database rejects invalid states too. That's the same belt-and-braces I'd build in Go.

Hexagonal architecture maps one-to-one. Models in one package, persistence in another, handlers in a third, transport (HTTP) at the edge. Pydantic models play the role of Go structs with validation tags; SQLAlchemy ORM models play the role of sqlx row types. The boundaries are identical; only the syntax differs.

Async-first thinking transferred without much friction. I expected this to be the hard part — goroutines feel native; Python's event loop is a thing you have to think about. In practice, asyncio with httpx and SQLAlchemy 2.0's async support gave me code that reads almost identically to Go. The big difference is await everywhere instead of implicit goroutine scheduling.

Database transactions as the contract. This is where I felt most at home. The race condition that hits every idempotent endpoint — two requests with the same key racing past the existence check — is handled with the same primitive in both languages: a unique constraint on the database, an IntegrityError on conflict, a re-read to find the winner. Postgres's correctness guarantees don't care what language is calling it.

What surprised me about Python

This is the section I'd been warned about. Most of the warnings were wrong.
Dependency injection feels heavier than Go's interfaces — but only at first. In Go I write a constructor, take an interface, done. In FastAPI I write a Depends() function, wrap it in Annotated, type-alias for readability, then reference it in every handler signature. It's more verbose. But after writing it a dozen times, I noticed something: the test ergonomics are actually better.

mypy --strict is a compiler — if you run it. This is the part Go engineers underestimate. Modern Python with mypy --strict plus Pydantic plus ruff catches almost everything the Go compiler would catch. The catch is "if you run it." Go enforces this on every build; Python relies on you to set up pre-commit hooks and CI. I built the hooks on day one and they paid for themselves within hours.

What I had to learn from scratch

A short list, but each item was real work:

Python's async model isn't Go's. Goroutines are preemptive, scheduled by the runtime, cheap. Python's coroutines are cooperative — they only yield at await points. If you write a CPU-bound function inside an async handler, the entire event loop blocks. This is the kind of thing the Go runtime saves you from. In Python you have to know it.
Connection pool sizing matters from minute one. When I ran my first load test (hey -n 1000 -c 50) I saw a long latency tail. I almost wrote it off as "Python being slow." Then I looked at my SQLAlchemy pool configuration: pool_size=10. With concurrency 50, 40 requests were waiting for connections. The same exact issue exists in Go; I just had production frameworks at NPCI that pre-tuned it for me. Building from scratch in Python forced me to learn what the framework was doing.

Alembic is genuinely better than go-migrate. Autogenerating migrations by diffing your ORM models against the live schema is a workflow Go doesn't really have. I was skeptical (autogen feels like magic) but reading the generated SQL before applying it is the right safety valve. I'll miss this when I'm back in Go.
Pydantic-settings makes config a non-issue. Type-safe, env-file-aware, validated at startup. Go has Viper or hand-rolled struct unmarshaling; both feel ad-hoc by comparison.

What I'd tell another Go engineer

Four things I wish I'd internalized on day one:

Don't try to make Python feel like Go. Lean into the idioms — Depends(), Annotated, Pydantic models, async context managers. Fighting the idioms wastes a week and produces unidiomatic code that other Python engineers will hate.
Set up mypy --strict and pre-commit hooks before writing a single business-logic line. This is the closest you'll get to Go's compile-time guarantees. Without it, you're writing JavaScript with type comments.
Build observability before features. I put structlog, OpenTelemetry, and Prometheus. Go engineers know this instinctively; Python tutorials skip it.
Python is faster to write than you think; slower to run than you'd hope. My benchmark hit 590 req/s. A Go equivalent would do 3-5x that on the same hardware. For most services this doesn't matter — you'll be bottlenecked on the database or the LLM API anyway. For some services it absolutely matters. Know which you're building.

The repo is here. The other repo with the FastAPI + observability + LLM gateway prototype is here. Both are pinned on my GitHub.

If you found this useful, follow me here or on GitHub — I'll be writing weekly through the rest of this transition.

DEV Community: Yogesh23012001

What a Go Engineer Learns Building Their First Real Python Service

What a Go Engineer Learns Building Their First Real Python Service

What a Go Engineer Learns Building Their First Real Python Service