// Topics / Performance

Performance

Definition

Performance coverage in this archive spans 10 posts from Aug 2017 to Mar 2024 and deals with structural tradeoffs: coupling, failure boundaries, and long-term change cost. The strongest adjacent threads are go, backend, and optimization. Recurring title motifs include go, caching, part, and postgresql.

Working claims

  • Most pieces recommend choosing the simplest architecture that can be operated confidently.
  • Early posts lean on go and stop, while newer posts lean on go and caching as constraints shifted.
  • This topic repeatedly intersects with go, backend, and optimization, so design choices here rarely stand alone.

How to apply this

  • Define failure domains and data boundaries before introducing additional services or protocols.
  • Start with the newest post to calibrate current constraints, then backtrack to older entries for first principles.
  • When boundary questions appear, cross-read go and backend before committing implementation details.

Where teams get burned

  • Breaking systems into many parts without clear ownership of cross-service behavior.
  • Choosing architecture for trend alignment rather than workload constraints.
  • Applying guidance from 2017 to 2024 without revisiting assumptions as context changed.

Suggested reading path

References

    LLM Prompt Caching in Go: Cut Costs Without Breaking Things Caching LLM responses is the highest-leverage optimization most teams are not doing. Here is how I implement it in Go, with real patterns for keys, invalidation, and safety. llm caching go Caching: The Easy Part Is Adding It, the Hard Part Is Everything Else Cache-aside, write-through, invalidation strategies, and the failure modes that will wake you up at night. With Go examples. caching redis performance PostgreSQL Performance: Measure First, Tune Second Most Postgres performance problems are indexing problems. The rest are vacuum problems. Here's how to find and fix both. postgresql databases performance Rust for Cloud Services: A Go Developer's Honest Take I write Go for a living. Rust is not replacing it. But I have to be honest about where Rust wins. rust go cloud eBPF Is Interesting. I Am Not Sold Yet. eBPF promises kernel-level observability without the pain of kernel modules. The tech is real. The hype-to-adoption ratio concerns me. ebpf observability linux Your Load Tests Are Lying to You Most load tests produce comforting numbers instead of useful answers. Here's what I learned the hard way about getting honest results. testing performance reliability The PostgreSQL Tuning Playbook I Actually Use Battle-tested PostgreSQL tuning from running fintech and startup workloads: connection pooling, memory sizing, index discipline, vacuum management, and the queries that tell you what's broken. postgresql database performance Making Go Services Fast: What Actually Matters Practical patterns for squeezing performance out of Go services — profiling, allocation control, bounded concurrency, and HTTP/DB tuning from real production work. go performance backend A Go Developer Looks at Rust for Backend Work I write Go every day at the fintech startup. Here's why I've been spending evenings with Rust, what impressed me, and where it still hurts. rust go backend Stop Guessing: How I Fix Slow Databases The repeatable process I use at the fintech startup to diagnose and fix database performance problems instead of throwing random indexes at the wall. databases performance postgresql