This repository is where I am collecting the patterns, dead ends, investigation habits, and performance engineering heuristics that held up under real delivery pressure.
I am not trying to write a tutorial, summarize vendor documentation, or produce a neat taxonomy of performance terms. I want a place to keep the things that were actually useful when latency got weird, throughput stopped scaling, dashboards were noisy, or a system looked healthy right until it wasn't.
This is not a tutorial repository and not a coding challenge repository. The goal is to document how I think about performance work in real delivery environments without exposing employer-specific implementation details.
What I keep coming back to:
- how to decide what to test and what not to waste time on
- how to model traffic in a way that still resembles production behavior
- how to figure out what is actually slow instead of guessing loudly
- how to translate test results into scaling and architecture decisions
- which signals I trust when a system starts bending under load
- which metrics look impressive but usually mislead
- reusable k6 patterns that stay generic enough for public sharing
- interview questions that reflect real engineering tradeoffs instead of trivia
All content in this repository is intentionally generic and public-safe.
- No internal project names
- No customer or product references
- No proprietary architecture
- No internal API shapes or endpoint names
- No copied company source code
- No internal schema, table, or package names
- No customer-specific metrics or screenshots
Where a real-world pattern is discussed, I have abstracted it into technology-focused guidance and fictional examples. If something feels specific enough to reveal an internal system, it does not belong here.
Most notes are written as reminders to my future self:
- what problem I was trying to solve
- what usually failed first
- which signals turned out to matter
- which explanations were tempting but wrong
- what I would check sooner next time
Some pages are closer to playbooks. Others are really collections of lessons learned. That imbalance is intentional.
- Foundations
- Methodologies
- Testing Strategies
- Bottleneck Analysis
- Capacity Planning
- Observability
- Benchmarking
- Datastores
- Architecture
- Anti-Patterns
- Interview Preparation
- Recommended Diagrams
- What I Learned Building k6 Test Suites
- Generic k6 examples
- Test plan template
- Capacity model template
- Start with Foundations for vocabulary and framing.
- Move to Methodologies and Testing Strategies.
- Use Observability, Bottleneck Analysis, and Benchmarking together during active investigation work.
- Use Capacity Planning and Architecture for scaling discussions.
- Use Interview Preparation as a concise review section.
Examples in this repository are intentionally generic:
- fictional endpoints and data models
- public-safe k6 scripting patterns
- synthetic throughput and latency assumptions
- vendor-neutral observability concepts
- architecture sketches using Mermaid diagrams
- Prefer hard-won observations over polished definitions.
- Document decision-making, not just tool usage.
- Write down what was misleading, not only what was correct.
- Keep examples production-inspired but non-proprietary.
- Update notes when experience changes the heuristic.