URL shorteners look simple until you realize the redirect path is the product. Every extra database call shows up directly in user latency.
Curlix was designed so analytics and ownership features exist, but never slow the hot path.
01The Redirect Path Has to Stay Boring
The happy-path redirect should do almost nothing: resolve the short code, return the long URL, and redirect. That is why Curlix keeps Redis in front of Postgres.
- Redis handles the common-case lookup in a few milliseconds.
- Postgres remains the source of truth on cache miss and for background processing.
- The user never waits for analytics writes on the redirect request.
02Why Analytics Moved Off the Request
A synchronous insert on every click was adding tens of milliseconds to each redirect. That cost was visible to every user but valuable to no user in the moment.
// before
await db.query('INSERT INTO analytics ...');
res.redirect(302, longUrl);
// after
analyticsQueue.add('click', payload);
res.redirect(302, longUrl);Moving analytics into BullMQ made click tracking fire-and-forget, which cut the redirect hot path down to the cache lookup and the HTTP redirect itself.
03Zero-Account Ownership
Curlix also avoided signup friction by issuing a bearer token when a link is created. That keeps the product fast to use while still giving the creator control over future edits.
04The Useful Tradeoff
- Fast redirects matter more than immediate analytics durability.
- Background workers are the right place for non-user-visible work.
- Caching only helps when the database is kept off the hot path by design.