Founding engineer · Retired · grew into tunyt · 2025
Tixin
Tixin started from the problem of hosting an event: the experience was harder than it needed to be for the people running it. I built it to make that easier, and designed it so a burst of bookings would not slow down people who were just browsing.
- Requests served
- 16K+/secload test, 1,000 concurrent, two-node Raspberry Pi 5 Kubernetes cluster, October 2025
- Events ingested
- 50K+/secsustained peak through the Kafka pipeline
- Query latency
- down 70%after PostgreSQL and MongoDB tuning on the booking read path
- Deploy time
- down 60%after rebuilding CI/CD automation
How I built it
Commands and reads take separate paths, which is CQRS. Commands go through Kafka and reads come from a Redis cache. That keeps reads fast and writes consistent when bookings arrive in a burst.
Two Raspberry Pis
I built the Kubernetes cluster myself, on two Raspberry Pi 5s. With two small nodes you can't hide a slow query or a chatty service behind more hardware, so I had to fix them.
What 16K means
The 16K requests a second came from a load test with 1,000 concurrent connections. It tells me the architecture wasn't the limit. I wouldn't quote it as capacity.
Afterwards
I pulled the read and write split into its own repo, cqrs, so you can read the pattern without the rest of the product.