Detailed component design

1. ID Generation Service

Avoiding collisions under concurrency: IDs come from a Snowflake-style generator: 41-bit timestamp + 8-bit server ID + 14-bit sequence counter, base62-encoded into an ~11-character code. Because the server ID is unique per instance, no two servers can produce the same (timestamp, server ID, sequence) triple — uniqueness is guaranteed with no collision-check retry loop, even under heavy concurrent creates.

Hard to guess: Codes are time-derived and base62-encoded, so they're non-sequential and opaque. A user cannot enumerate or predict valid short links — attempting to scan the space is infeasible.

Generator outage / split-brain: Each instance runs its own generator with a server ID assigned at startup. If one generator dies or is partitioned, the remaining instances keep issuing unique IDs — there is no central generator to fail, so no split-brain window exists.

2. Caching Layer

Cache-aside pattern: The read path checks Redis first. On hit, the long URL returns in <1ms. On miss or TTL expiry, the Redirect Service queries DynamoDB, serves the redirect, and populates Redis — so the next request is served from cache.

TTL & eviction: Each entry gets a 24-hour TTL. Viral links refresh their TTL on every hit, so hot entries stay cached; cold links expire naturally, preventing memory bloat without manual eviction logic.

Purging on update/disable: When a link is edited or disabled, the service actively deletes the key from Redis so changes take effect immediately — no stale redirects.

Viral link protection: Redis absorbs the read spike for a suddenly popular link, so the database never sees the full load. For extreme virality, a CDN edge layer can cache the 302 response at the network edge.

3. Partitioning (Database Sharding)

Single-shard lookups: The database is partitioned on hash(short_code). Every redirect routes to exactly one shard — no scatter/gather, so latency stays consistent at any scale.

Even spread + hotspots: Because short codes are random, traffic distributes evenly across shards. A viral link is served by Redis/CDN before reaching the DB, preventing any single shard from being overwhelmed.

4. Rate Limiting

Mechanism: A distributed token bucket runs at the API gateway, backed by Redis. Each client (keyed by IP or API token) has a bucket — e.g., 100 tokens/min for creates, 1,000 tokens/min for redirects. Every request consumes a token.

Burst handling & backoff: Bursts are smoothed by the refill rate. When a bucket is empty, the gateway returns 429 Too Many Requests with a Retry-After header so clients back off automatically.

Management: Because the bucket state lives in Redis, all gateway instances share it — a client can't bypass limits by hitting different instances. Limits are configurable per tier (anonymous vs. registered users), adjustable at runtime without redeploy, and monitored for anomalies (e.g., a client suddenly spiking).

5. Scaling & High Availability

Scaling: Services are stateless → scale horizontally behind the ALB. DynamoDB scales automatically via partitioning. Redis scales via cluster mode (keys sharded across nodes, replicas for read scaling).

High availability: Services run across multiple availability zones; the ALB health-checks and routes around dead instances. DynamoDB replicates synchronously within the region (immediate durability) and asynchronously to a standby region for disaster recovery. Redis uses replica sets with automatic failover — a cache loss degrades to DB reads, never downtime.

6. Security

In transit: HTTPS-only (TLS 1.3), terminated at the ALB.

At rest: DynamoDB and Redis use server-side AES-256 encryption via AWS KMS.

SQL injection: DynamoDB is NoSQL — there is no SQL to inject; all lookups are parameterized key-value gets. The gateway additionally enforces a strict character allowlist for short codes ([a-zA-Z0-9]), so malicious payloads never reach the data layer.

XSS: Short URLs are opaque identifiers, never rendered as content. On create, the service validates and sanitizes the long URL — rejecting javascript: URIs and non-http(s) schemes — so redirect targets are always safe. Responses never echo user input.

DDoS: AWS Shield absorbs volumetric attacks at the network edge; AWS WAF blocks known attack signatures (SQLi patterns, XSS payloads, bad bots); rate limiting prevents application-layer exhaustion.

Database Design

Schema: The core table is URL_MAPPINGS with id (BIGINT PK), short_code (VARCHAR(10), unique indexed), long_url (TEXT), created_at, expires_at (nullable, for expiring links). A unique index on short_code is the primary lookup path for redirects.

Storage engine: DynamoDB (or Cassandra). Single-key lookups match the workload perfectly, it scales horizontally, supports strong reads on create, and has built-in TTL for expires_at. A relational DB would require manual sharding later.

Partitioning: Shard on hash(short_code). Each redirect hits exactly one shard (no scatter/gather), and since codes are random, traffic distributes evenly.

Consistency: Strong on creation — guarantees a short code is never duplicated. Eventual on redirect reads — a brief delay before a new code propagates only risks a transient miss.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10