Microservices & API Architecture
Splitting a system into services trades one set of problems for another: partial failures, retries that amplify an outage, events that get lost, and connections that die quietly between calls. These guides and Q&A threads cover decomposing a monolith incrementally, reliable messaging with RabbitMQ, resilience patterns, and the specific gRPC, GraphQL and Python behaviours that cause intermittent production errors.
3 guides · 3 Q&A threads
Guides
Retries, Backoff and Circuit Breakers in Python with tenacity and pybreaker
Every call from one service to another can fail or hang. Handled badly, a slow dependency ties up threads and connections in its callers until they fail too. Two patterns address this from opposite di...
The Strangler Fig Pattern in Practice: Routing, Cutover and Data
Rewriting a large monolith from scratch is risky: the old system keeps changing while the new one is built, and nothing reaches users until the switch-over at the end. The Strangler Fig pattern avoids...
RabbitMQ Events in Python: Durable Queues, Publisher Confirms and Dead-Lettering
When services call each other synchronously over HTTP, a slow or failing service holds up everything that depends on it. Publishing events through a message broker removes that runtime dependency. The...
Q&A
gRPC UNAVAILABLE on the First Call After Idle: Load Balancer Timeouts and Keepalive Settings in Go
Two Go services talk over gRPC: an order service (client) calls an inventory service (server) to reserve stock before confirming an order. The inventory service runs on Kubernetes in AWS, and the orde...
Apollo Server and TypeORM: N+1 User Queries Even Though a DataLoader Is in the Context
A product catalog API built with Apollo Server 4, TypeGraphQL and TypeORM returns products, their reviews, and each review's author. A DataLoader for users is created once per request and placed in th...
Python multiprocessing Manager().dict(): Why Appends to Nested Lists Don't Show Up in Other Processes
A common pattern for collecting results from multiprocessing workers is a shared multiprocessing.Manager().dict(). Each worker reports its status into the dictionary, and the main process reads it at...