Skip to content

Practical Engineering Techniques

These techniques recur across algorithms, APIs, databases, concurrent programs, and distributed systems. Each solves a recognizable class of problems, but each also introduces a contract that must be made explicit.

How to choose a technique

Need Start with Question that prevents misuse
Avoid repeated pure computation Memoization Is the complete input part of the key?
Reuse data across requests Application caching How may the value become stale?
Amortize per-operation overhead Batching, buffering, and chunking What bounds memory and waiting time?
Defer unnecessary work Lazy processing Who owns resources when evaluation occurs?
Return large ordered result sets Pagination Is the ordering unique and stable?
Survive transient failure Retries and deadlines Is another attempt safe and still useful?
Make repetition safe Idempotency What defines the same logical operation?
Protect limited capacity Resilience controls Where is overload admitted or rejected?
Coalesce frequent signals Debouncing and throttling May intermediate events be discarded?
Share scarce resources Pools and bounds What happens at saturation?
Protect ownership boundaries Defensive copying Is the entire reachable state immutable?
Separate external and domain models DTO mapping and validation Which boundary owns each rule?
Publish reliably after a commit Transactional outbox How are duplicates and ordering handled?
Remove inefficient data access Query optimization What evidence identifies the bottleneck?
Understand production behavior Logs, metrics, and traces Can signals be correlated safely?
Explain performance and failures Debugging and profiling Which measurement tests the hypothesis?
Test broader contracts Testing techniques Which defects can this test level detect?

A common decision loop

  1. State the observable problem and the correctness contract.
  2. Measure the current behavior and establish a baseline.
  3. Select the smallest technique that addresses the identified cause.
  4. Define capacity, timeout, failure, ownership, and consistency policies.
  5. Test normal behavior, boundaries, saturation, and recovery.
  6. Observe the result in production and remove accidental complexity.

A familiar technique is not automatically the right one. A cache can hide a slow query, retries can amplify an outage, and a pool can convert overload into unbounded waiting. Correctness and operational behavior remain part of the design.