// Topic
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
- Start here (current state): LLM Prompt Caching in Go: Cut Costs Without Breaking Things
- Then read (operating middle): Your Load Tests Are Lying to You
- Finish with (foundational context): Stop Guessing: How I Fix Slow Databases
Related posts
- LLM Prompt Caching in Go: Cut Costs Without Breaking Things
- Caching: The Easy Part Is Adding It, the Hard Part Is Everything Else
- PostgreSQL Performance: Measure First, Tune Second
- Rust for Cloud Services: A Go Developer’s Honest Take
- eBPF Is Interesting. I Am Not Sold Yet.
- Your Load Tests Are Lying to You
- The PostgreSQL Tuning Playbook I Actually Use
- Making Go Services Fast: What Actually Matters
References
10 posts
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.