Class 10 Post-Class: Extend the URL Shortener
Custom Alias + Real-Time Analytics

One of the most common interview follow-ups is: “We've designed the basic system. Now the product team wants feature X. How would you extend the architecture?” This tests your ability to modify an existing design incrementally — adding components without rewriting the system.

Today's exercise extends the URL Shortener from Class 9 with two features: a Custom Alias System (vanity URLs like sho.rt/my-brand) and a Real-Time Analytics Dashboard (clicks, geography, referrers, unique visitors).

Figure 1: Two extensions — Custom Alias System (5 sub-features) and Real-Time Analytics (5 sub-features)

A custom alias allows users to choose their own short code (e.g., sho.rt/my-brand instead of sho.rt/abc1234). This seems simple but introduces several design challenges: validation (what characters are allowed?), uniqueness (what if the alias is already taken?), suggestions (how to help users find available alternatives?), and reservation (how to protect brand names from squatting?).

Figure 2: Custom alias create flow — validate format, check availability, INSERT with UNIQUE constraint, return 201 or 409 with suggestions

Figure 3: Before vs After schema — short_code expanded to VARCHAR(20), two new columns added

-- Widen short_code to accommodate custom aliases up to 20 chars
ALTER TABLE urls
  ALTER COLUMN short_code TYPE VARCHAR(20);

-- Distinguish custom from generated codes
ALTER TABLE urls
  ADD COLUMN is_custom   BOOLEAN NOT NULL DEFAULT FALSE,
  ADD COLUMN alias_type  VARCHAR(10) NOT NULL DEFAULT 'generated';
-- alias_type values: 'generated' | 'custom' | 'premium'

-- New reserved aliases table (brand protection)
CREATE TABLE reserved_aliases (
  alias       VARCHAR(20)  PRIMARY KEY,
  reason      TEXT,
  reserved_at TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

-- Partial index for "my custom aliases" page
CREATE INDEX idx_urls_user_custom
  ON urls (user_id, is_custom)
  WHERE is_custom = TRUE;
-- Existing UNIQUE index on short_code handles both generated and custom codes

As the user types their desired alias, the frontend sends a debounced availability check (GET /api/v1/alias/check?q=my-bra) every 300ms. The API checks a Redis Bloom filter containing all existing short codes.

Figure 4: Type-ahead availability — 300ms debounce, Bloom filter check, instant “available” or “probably taken” response

A Bloom filter with 6 billion entries and a 1% false positive rate requires approximately 1 GB of memory — 14× less than storing all codes in a Redis SET. The Bloom filter returns one of two results:

• Definitely available — no DB query needed (99% of checks). Show green checkmark instantly.
• Probably taken — verify against PostgreSQL to confirm (1% false positive rate). May add ~5ms latency.

The analytics feature tracks every click and presents the data in a real-time dashboard. The critical design constraint: analytics must have zero impact on redirect latency. The redirect path (GET /{code}) must return 301/302 in under 1ms. All analytics processing happens asynchronously after the redirect response is sent.

Figure 5: Complete analytics pipeline — click events → Kafka → three consumers: Redis (real-time), Flink (streaming), ClickHouse (historical)

ClickHouse is a columnar database optimized for analytics queries. It stores click events partitioned by day, enabling efficient time-range queries and automatic archival of old data. Columnar storage compresses click data approximately 10× (a 1 TB dataset occupies ~100 GB on disk). Aggregation queries (count clicks by country, group by referrer) scan only the needed columns, making them 10–50× faster than equivalent PostgreSQL queries on the same data.

Figure 6: ClickHouse schema and four common query patterns — all completing in under 50ms on billions of rows

CREATE TABLE click_events (
  event_id     UUID,
  short_code   VARCHAR(20)   NOT NULL,
  clicked_at   DateTime      NOT NULL,
  country      VARCHAR(2),                 -- pre-computed from GeoIP
  city         VARCHAR(100),
  device_type  VARCHAR(20),                -- mobile | desktop | tablet
  browser      VARCHAR(50),
  referrer     TEXT
)
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(clicked_at)     -- partition by day
ORDER BY (short_code, clicked_at)      -- primary sort key
TTL clicked_at + INTERVAL 2 YEAR;       -- auto-delete after 2 years

Figure 7: Three Redis counter types — INCR (total/daily), HyperLogLog (unique visitors), Sorted Set (hourly heatmap)

The dashboard uses a hybrid data source strategy: each endpoint reads from whichever store provides the fastest, most accurate answer for that specific type of data.

Figure 8: Five dashboard API endpoints — each backed by the optimal data source

The extended architecture adds three new components to the base URL Shortener design from Class 9. Critically, the redirect hot path (GET /{code}) is completely unchanged. The CDN, Redis cache, and PostgreSQL redirect flow work identically for both generated codes and custom aliases — the UNIQUE index on short_code handles both transparently.

Figure 9: Complete extended architecture — base components (gray) plus new Alias Service, Analytics Pipeline, and Dashboard API

Figure 10: 12-point checklist covering both extensions — custom alias system and real-time analytics