URL Shortener

A short-link request has an immediate job: look up a destination and send the browser there. Recording that click is a separate job with different storage and query needs. This project uses that distinction to explore caching, asynchronous processing and the cost of operating a distributed application.

The implementation combines Django, PostgreSQL and Redis for URL creation and lookup, with Kafka and ClickHouse for analytics. The recorded k6 runs reach 292 requests per second at 500 virtual users and 330 at 1,000. Those figures are useful because the accompanying latency measurements expose where adding concurrency stops paying off.

Writing each click to an analytical store before returning a redirect couples user-visible latency to analytics ingestion. Moving that work into a pipeline reduces that coupling, but it introduces a different question: when can the application honestly say a click has been recorded?

The architecture therefore has two goals to evaluate separately: fast URL resolution and reliable event processing. A successful redirect is not proof that an analytics row has already been stored. Treating these as separate outcomes makes both the monitoring and the failure cases clearer.

An incrementing Redis counter supplies an integer that is encoded as Base62. The attraction is operational simplicity: requests using the same counter receive distinct increments rather than generating random candidates and retrying collisions.

That property depends on preserving the counter and coordinating its use. Resetting it while old mappings still exist can reuse identifiers. Sequential identifiers are also predictable, so a short code must not be treated as an access-control secret. The useful claim is uniqueness within the maintained allocation scheme, not an unconditional guarantee under every recovery scenario.

The consumer excerpt commits offsets after a successful batch insert. If insertion fails, keeping the offsets uncommitted leaves an opportunity to retry. But if insertion succeeds and the process fails before committing, the same records may be processed again. This is the gap where duplicate handling matters.

Exactly-once behavior across an external database requires more than manual commits. This portfolio does not present a verified deduplication protocol or failure-injection results. The architecture supports a discussion of retries and replay; it does not establish loss-free delivery under all failures.

The excerpt checks the flush interval inside the message loop. That distinction matters when traffic becomes quiet: a partially filled buffer does not get another time check until control returns to the condition. A complete consumer needs an idle-time flush mechanism or an equivalent polling design, plus a shutdown policy.

Batching trades fewer database writes for a delay before events become queryable. Buffer length, time since the last successful flush and consumer lag are useful follow-up measurements because they describe that delay directly. Request success rate alone cannot show an analytics pipeline falling behind.

Doubling virtual users increases throughput by about 13%, while median latency rises from 575 to 1,330 milliseconds and p95 from 1,610 to 2,850 milliseconds. The system completes more work, but each user waits longer. The recorded zero error rate is encouraging for those runs; it does not make the longer wait disappear.

This pattern suggests saturation and queueing somewhere along the tested path. Pinpointing the limiting service requires time-aligned request and infrastructure measurements. An earlier CPU note in this case study referred to a two-core backend limit, while the configuration table lists one core, so that note cannot establish the bottleneck for this configuration.

The earlier 1–2 millisecond cache-path estimate is not comparable to the end-to-end k6 latency distribution. A rerun should record the exact request mix, cache warm-up, test duration, load-generator location, service configuration and commit. It should distinguish redirect latency from the delay until a click appears in analytics.

The resource table describes configured limits for the listed services, not measured consumption or a complete bill for every monitoring container. A cached redirect benchmark also does not establish the capacity of URL creation, cache-miss lookups or expensive analytics queries.

The metrics excerpt uses a formatted latency value as a Redis sorted-set member. Equal formatted values share a member, so repeated measurements can overwrite one another rather than count as separate observations. That can affect a percentile calculation built from the set. A production revision should give each observation a unique identity or use a suitable histogram.

This is a useful reminder when comparing a custom dashboard with a load generator: first check whether they measure the same requests, time window and aggregation. A mismatch is a reason to inspect the measurement path before tuning the application.

The project makes the trade-offs visible: a cache changes lookup cost, an event stream changes when work completes, and a separate analytical database changes where queries consume resources. Each addition introduces a new state to observe and a new failure to test. The next improvement should be chosen from measured latency or delivery behavior, rather than adding another service by default.