Topic
Reliability & Operations
Failure handling, observability, and lessons from operating distributed systems.
Append, Don’t Overwrite: Designing Immutable Operational Data
An append-only repayment example that makes history and synchronization clearer, along with the storage and query costs it introduces.
Turn Production Incidents into Shared Domain Knowledge
Use incident reviews, working notes, concept maps, and rotated operations to reduce domain knowledge gaps across a software team.
Track Database Changes with the Work That Ships Them
Collect database changes with the issue and PR that need them, test them in development, and hand off the final release set before code deployment.
What Repeated Failure Teaches a Developer Career
Career failures become useful when they change how you verify opportunities, value trusted referrals, and revise the rules you made from earlier setbacks.
Modernize Legacy Systems Gradually—and Treat Caches as Operations
Choose legacy boundaries carefully, change them in small steps, and add a shared cache only after DB work and deployment failure modes are understood.
Design Performance Tests from Real Traffic Shapes
Estimate volume and arrival patterns before choosing a load test, add deliberate headroom, and require evidence only where traffic risk justifies it.
Foreign Keys Are an Operational Tradeoff, Not a Rule
Choose foreign keys, indexes, and ORM mappings from integrity needs, incident response, deployment practice, and who operates the database.
Put Circuit Breakers Next to the Failing I/O
Circuit breakers, timeouts, cache fallbacks, and remote-call policies belong near the implementation that performs the I/O, while domain code chooses the required behavior.
Timeouts Are Product Decisions, Not Just Client Settings
Design timeout, retry, and recovery policies from the user's waiting budget and the uncertainty of each failure instead of applying one retry rule everywhere.
When an AI Agent Calls the Same Tool Twice
Retries are normal in distributed systems and AI workflows. Use database constraints, idempotency keys, and bounded retries to prevent duplicate side effects.
Operate Your Toy Project Before Calling It a Service
A toy project becomes service experience only after launch: pick one goal, find real users, watch retention, and learn when to stop.
Carry One Trace ID across Distributed Services
Logs become operationally useful when one request can be followed across HTTP calls and asynchronous events without exposing sensitive data or flooding storage.