Engineering beyond
the happy path.
Field notes on building Python systems that hold up in production.
The decisions, the trade-offs, and the code behind them.
Explore all articles below. Browse the archive →
A few good places to start
Follow your curiosityThe articles
Notes from the infrastructure layerWhy AI review findings need verification
Many teams now run an AI reviewer on merge requests. It writes findings as confidently as a senior colleague, but confidence does not make a finding true.
Why extract Python service infrastructure into libraries
Once there is more than one service, they start sharing plumbing: connection pools, retries, request deadlines, shutdown order.
Documentation that lets an AI coding agent write checkable code
More and more service code is written by AI coding agents, and they write it from whatever documentation the project has.
A Python library from template to release
Small shared code often lives as copies: each service has its own helper, and over time they drift apart.
A core without dependencies: install the integrations your service needs
An infrastructure library ends up in many services, and each of its mandatory dependencies lands in every one of them, including those that never use it.
PostgreSQL partition maintenance: from a plan to a verified archive
Monthly partitions need routine care: every month someone has to create next month's table and retire an old one.
Partitioning an existing PostgreSQL table
An events table grows for years until its size gets in the way of queries and cleanup, and it gets split into monthly partitions.
Testing Alembic migrations in CI
Schema migrations are usually checked in CI with one step: apply them to an empty database. If the step is green, the migration is considered safe.
SQLAlchemy and PgBouncer: configuring and diagnosing connection pools
Once there are enough services and pods, PostgreSQL runs out of connections and PgBouncer goes in front of it.
SQLAlchemy sessions and transactions: who owns commit
Picture the order service of an online shop. A customer places an order, and the service saves it and writes a created event that tells the warehouse and delivery about it.
Reliable event delivery with Outbox, Inbox and Kafka
Picture this: a customer places an order. The order service saves it in PostgreSQL and publishes an event to Kafka. Billing reads the event and issues an invoice.
Kafka in Python: publishing, processing and stopping safely
A delivery service publishes parcel statuses to Kafka, and a tracking service reads them to show buyers where their order is.
Redis is down: which routes keep working, and why PING won't tell you
In an online shop, Redis usually sits next to the main database: it caches prices, counts login attempts and gates repeated payment clicks. While it works, nobody thinks about it.
Preparing a Python gRPC server for production
Starting a gRPC server in Python is easy: a handler and a few lines of startup code. Making it behave predictably when things go wrong is the hard part.
The Python service lifecycle: startup, health checks and shutdown
A service in Kubernetes restarts all the time: on every rollout, on scaling, when a pod moves to another node.
Idempotency in APIs and background jobs
Networks lose responses, users click twice and brokers redeliver messages. Sooner or later, any request or job arrives twice.
Building HTTP and gRPC clients for production
An orders service calls a warehouse and a payment service, and either can be slow or not answer at all. The first instinct is to retry.
Why gRPC interceptors break on streaming RPCs
gRPC interceptors are usually written once, so that logging, metrics and tracing cover every call.
Timeouts are not deadlines: how latency budgets break across microservices
A user request rarely stays in one service. It passes through a chain of calls, each with its own timeout, and that looks like enough to keep it from hanging.
No articles found. A different angle?
Try a broader term like “retries” or “PostgreSQL”, or clear a filter.