How we build Trekpoint
Practical write-ups on architecture, APIs, infrastructure, and the product decisions that shape our stack.
From the blog
-
The Production Scheduler Footgun: Celery Beat in Config, Missing in Reality
Some production problems are subtle scaling pathologies.
-
Why We Chose Kamal Over Kubernetes for a Multi-Region Routing Gateway
Not every production service needs a platform story big enough to impress conference slides.
-
The Stripe Webhook Decision I’d Revisit: Re-Fetching Events by ID Instead of Verifying Signatures
I like writing about decisions that were reasonable, shipped, and still worth revisiting.
-
Redis Quietly Became Our Tiny Control Plane
Redis starts innocently in most web apps.
-
Designing an OpenAPI Contract for a Product That Is Not Just an API
A lot of engineering teams treat OpenAPI as paperwork. The spec gets updated at the end, the examples go stale, and everyone agrees the code is the real source of truth.
-
Observability in a Flask + Celery App Is Easy Until You Instrument It Twice
Most observability tutorials assume a simpler world than the one production Python apps actually live in.
-
Observability Before `app.listen()`: Preloading OpenTelemetry, Sentry, and Pino in Node
There are two ways teams usually add observability.
-
The Hidden Complexity of GPX and FIT Support in a Route-Planning Product
“Supports GPX and FIT” is the kind of bullet point that looks tiny on a pricing page.
-
The Rate Limiter Worked in Staging and Failed in Production: Identity, Replicas, and Shared Counters
One of my favorite engineering stories is when the code is technically correct and operationally wrong.
-
If the Queue Is Down, the Upload Still Has to Work
One of the clearest signals that a product has seen real users is how it behaves when infrastructure is unhealthy.
-
Retries Are Not Resilience: Adding Per-Region Circuit Breakers to a Node Gateway
A retry loop is one of the first resilience features teams add. It is also one of the first ones they overtrust.
-
Building an OAuth Provider Inside the Product Changes More Than Authentication
Many products talk about “opening up an API” as if it is a documentation task.
-
Why Our Fastest Cache Was Not Redis: Designing a Two-Tier Cache for Geospatial APIs
Redis is a great cache. It is also not free.
-
We Didn’t Gate Trek Point by Plan Name. We Gated It by Entitlements.
One of the fastest ways to paint yourself into a corner in SaaS billing is to use commercial plan names as if they were product capability definitions.
-
Seat-Based Billing Is Mostly an Invariants Problem
The first version of org billing usually looks easy on a whiteboard.
-
We Stopped Reverse-Geocoding Every Point: The Sampling Trick That Made Multi-Region Routing Affordable
Performance work is often less about clever algorithms and more about refusing to do expensive work you do not actually need.
-
The SEO Tax of Localization: Clean URLs, Canonicals, and the Stuff Nobody Puts in the Demo
Adding another language to a product sounds straightforward when described in product terms:
-
How to Fake a Vendor API the Right Way: Serving Mapbox Directions from Valhalla
Compatibility layers are easy to underestimate. On the surface, they look like translation work. In reality, they are product work.
-
Subdomains Are a Product Boundary, Not Just a DNS Detail
Before we shipped Trek Point broadly, I thought about subdomains mostly in branding terms:
-
Crossing Oceans Without a Global Router: How We Stitched Routes Across Regional Valhalla Clusters
Routing gets surprisingly hard the moment your data stops living in one place.
-
Why We Kept Trek Point a Monolith Longer Than Most People Would
When people hear “route-planning SaaS,” they often assume the backend must already be split into map services, billing services, auth services, and some kind of developer platform. That sounds neat on a diagram. It is also an easy way to spend months building organizational overhead before the product earns it.
-
One Endpoint, Four Regions, Zero Client Changes: Inside a Geo-Sharded Routing Gateway
Most API gateway articles are really about request forwarding. This one is about orchestration.
Subscribe via RSS