Projetando um URL Shortener em Escala: Guia Definitivo de System Design

Resumo: Um guia completo para projetar um encurtador de URL como bit.ly e TinyURL, cobrindo geração de chave, redirecionamento, cache, analytics em tempo real, segurança, multi-região e operação em escala global.

Publicado: Fevereiro 2026 Tempo de leitura: 60 minutos Palavras-chave: #SystemDesign #URLShortener #Bitly #TinyURL #SistemasDistribuidos #Escalabilidade #Cache #Analytics #EntrevistaTecnica

Uma URL curta parece um detalhe de produto. Na prática, ela é um problema de infraestrutura sério.

Quando um usuário clica em https://s.ua/abc123x, você tem poucos milissegundos para resolver o código curto, validar expiração, decidir política de redirect, registrar evento de analytics, bloquear abuso, e devolver resposta de forma confiável. Tudo isso sem travar o caminho quente.

A maior parte das pessoas subestima esse tipo de sistema porque o produto final é simples. Entrevistadores fazem o mesmo problema justamente por isso: ele expõe maturidade em arquitetura, modelagem de dados, trade-offs de consistência e pensamento operacional.

Este guia segue o mesmo padrão técnico da série: começamos por requisitos, fazemos cálculos, desenhamos arquitetura, e entramos no detalhe das decisões que separam um sistema didático de um sistema pronto para produção.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Design de API
• Algoritmos de Encurtamento: O Problema Central
• Key Generation Service (KGS)
• Mecanismo de Redirect: 301 vs 302
• Modelagem de Dados
• Escolha de Banco: SQL vs NoSQL
• Estratégia de Cache
• Sistema de Analytics
• Aliases Customizados
• Expiração e Cleanup
• Rate Limiting
• Segurança
• Distribuição Global
• Confiabilidade e Tolerância a Falhas
• Dicas de Entrevista
• Anti-Patterns para Evitar
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

A ordem aqui importa. Sem requisitos claros, você escolhe tecnologia cedo demais e quase sempre otimiza o lugar errado.

Requisitos Funcionais

Obrigatórios (MVP sério):

1. Criar URL curta a partir de URL longa.
2. Redirecionar URL curta para URL original.
3. Evitar colisão de chave curta.
4. Suportar expiração opcional por data ou TTL.
5. Analytics básico por link: cliques totais, únicos, origem e dispositivo.
6. Desativação de link.

Importantes (produção):

1. Alias customizado (s.ua/minha-campanha).
2. API autenticada para integrações.
3. Rate limit por plano (anônimo, free, pro).
4. Proteção contra abuso (phishing, malware, spam).
5. Dashboard de analytics com agregações.

Opcional (evolução):

1. QR code automático.
2. Bulk shortening via CSV/API.
3. Webhooks de eventos.
4. A/B redirect por regra.

Requisitos Não Funcionais

Assumptions de Escala

• 100M links novos por mes.
• Razão leitura/escrita: 100:1.
• Pico de 5x em eventos.
• 10 anos de retenção para mapeamento.

Por que isso muda o design

Esse sistema é read-heavy por natureza. Se você modela como sistema de escrita, erra no primeiro dia.

A decisão principal não é banco SQL ou NoSQL. A decisão principal é: como garantir lookup de redirect extremamente rápido e barato no caminho quente, sem sacrificar integridade de mapeamento.

Cálculos de Envelope

Em entrevista, cálculo não é enfeite. Ele define o desenho.

QPS de Escrita e Leitura

Links novos por mês: 100,000,000
Segundos por mês (30 dias): 2,592,000
QPS médio de escrita: 100,000,000 / 2,592,000 ~= 38.6 ~ 40/s
QPS pico (5x): 200/s

Razão leitura/escrita: 100:1
QPS médio de leitura: 4,000/s
QPS pico: 20,000/s

Estimativa de Armazenamento

Assumindo 300 bytes por registro de mapeamento (com metadados básicos):

100M/mês * 12 * 10 anos = 12 bilhões de links
12,000,000,000 * 300 bytes = 3.6 TB (dados crus)
Com índice + overhead (2x): 7.2 TB
Com replicação (3x): 21.6 TB

Espaço de Chaves

Com Base62:

62^6 = 56.8 bilhões
62^7 = 3.52 trilhões

Para 12 bilhões de links em 10 anos:

• 6 chars funciona no papel, mas apertado para reservas e crescimento.
• 7 chars oferece folga real.

Decisão recomendada: 7 chars no caminho padrão.

Memória para Cache Quente

Se 20% dos links recebem 80% dos cliques:

Assuma 20M chaves quentes
20,000,000 * 300 bytes = 6 GB
Com overhead de estrutura (Redis): ~10-14 GB

Cache quente cabe com folga em cluster pequeno.

Insight que guia o resto

• Armazenamento não é o principal gargalo.
• Gargalo é latência + throughput de redirect + custo de analytics.

Arquitetura de Alto Nível

Explicação direta da arquitetura

• Write path é separado de read path para escalar cada lado isoladamente.
• Redirect service consulta cache primeiro e réplica de leitura depois.
• Analytics nunca bloqueia redirect. Evento vai para fila assíncrona.
• KGS evita geração de chave no request path quando necessário.
• WAF + rate limiting reduz custo de tráfego inválido antes do backend.

Design de API

Contratos Principais

export interface ShortenRequest {
  longUrl: string;
  customAlias?: string;
  expiresAt?: string; // ISO 8601
  campaign?: string;
  tags?: string[];
}

export interface ShortenResponse {
  shortCode: string;
  shortUrl: string;
  longUrl: string;
  createdAt: string;
  expiresAt: string | null;
  qrCodeUrl?: string;
}

export interface RedirectResult {
  location: string;
  statusCode: 301 | 302;
}

export interface UrlStatsResponse {
  shortCode: string;
  totalClicks: number;
  uniqueClicks: number;
  topCountries: Array<{ code: string; clicks: number }>;
  topReferrers: Array<{ domain: string; clicks: number }>;
  topDevices: Array<{ device: string; clicks: number }>;
}

Endpoints REST

POST   /api/v1/urls
GET    /:shortCode
GET    /api/v1/urls/:shortCode
DELETE /api/v1/urls/:shortCode
GET    /api/v1/urls/:shortCode/stats
GET    /api/v1/users/:userId/urls?cursor=...&limit=...

Exemplo de Criação

curl -X POST https://s.ua/api/v1/urls \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "longUrl": "https://example.com/campanha/lancamento?utm_source=mail",
    "expiresAt": "2026-12-31T23:59:59Z",
    "campaign": "lancamento-q4"
  }'

Resposta esperada:

{
  "shortCode": "aZ8k2Pm",
  "shortUrl": "https://s.ua/aZ8k2Pm",
  "longUrl": "https://example.com/campanha/lancamento?utm_source=mail",
  "createdAt": "2026-02-15T18:20:41.000Z",
  "expiresAt": "2026-12-31T23:59:59.000Z"
}

Exemplo de Redirect Handler

import type { Request, Response } from "express";

export async function redirectHandler(req: Request, res: Response): Promise<void> {
  const shortCode = req.params.shortCode;

  if (!/^[a-zA-Z0-9_-]{1,32}$/.test(shortCode)) {
    res.status(400).json({ error: "invalid_short_code" });
    return;
  }

  const cacheKey = `url:${shortCode}`;
  let record = await redis.get(cacheKey);

  if (!record) {
    record = await urlRepo.findActiveByShortCode(shortCode);

    if (!record) {
      res.status(404).json({ error: "not_found" });
      return;
    }

    if (record.expiresAt && new Date(record.expiresAt) <= new Date()) {
      res.status(410).json({ error: "expired" });
      return;
    }

    await redis.set(cacheKey, JSON.stringify(record), "EX", 3600);
  }

  // Fire-and-forget analytics
  analyticsProducer.publishClick({
    shortCode,
    ts: Date.now(),
    ip: req.ip,
    userAgent: req.headers["user-agent"] ?? "",
    referrer: req.headers["referer"] ?? "",
  }).catch(() => undefined);

  const payload = typeof record === "string" ? JSON.parse(record) : record;
  res.redirect(payload.redirectType ?? 302, payload.longUrl);
}

Algoritmos de Encurtamento: O Problema Central

A pergunta central é: como gerar um shortCode único, curto, barato e operável?

Abordagem 1: Base62 de ID incremental

const ALPHABET = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";

export function encodeBase62(n: bigint): string {
  if (n === 0n) return ALPHABET[0];

  let x = n;
  let out = "";

  while (x > 0n) {
    const r = Number(x % 62n);
    out = ALPHABET[r] + out;
    x = x / 62n;
  }

  return out;
}

Pro: simples, sem colisão, fácil de depurar.

Contra: previsível e enumerável.

Abordagem 2: Hash truncado

import { createHash } from "crypto";

export function hashBasedCode(longUrl: string): string {
  const hex = createHash("sha256").update(longUrl).digest("hex");
  const slice = hex.slice(0, 12);
  const n = BigInt(`0x${slice}`);
  return encodeBase62(n).padStart(7, "a").slice(0, 7);
}

Pro: sem contador central.

Contra: colisão inevitável com truncamento, precisa estratégia de retry.

Abordagem 3: Pool pré-gerado (KGS)

• gera chaves offline.
• marca chaves como disponíveis/reservadas/usadas.
• app server pega lote para buffer local.

Pro: caminho de escrita previsível, colisão praticamente eliminada.

Contra: adiciona serviço operacional extra.

Abordagem 4: Snowflake + Base62

// 41 bits timestamp | 10 bits worker | 12 bits sequence

Pro: distribuído e ordenável no tempo.

Contra: exige controle de clock e worker IDs.

Abordagem 5: Random + check

export function randomCode(len = 7): string {
  const chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
  let out = "";
  for (let i = 0; i < len; i++) {
    out += chars[Math.floor(Math.random() * chars.length)];
  }
  return out;
}

Pro: fácil de implementar.

Contra: cresce custo de colisão com volume alto.

Comparativo prático

Escolha recomendada para produção

• Padrão: Snowflake + Base62 (7 chars iniciais, expansível).
• Para ambiente mais simples: ID + Base62 com ofuscação.
• Para controle forte de capacidade: KGS com prefetch em lote.

Key Generation Service (KGS)

KGS é útil quando você quer previsibilidade total no caminho de criação.

Fluxo

1. Job offline gera pool de chaves.
2. KGS reserva lotes para cada app server.
3. App server consome chave localmente (sem chamada remota por request).
4. Em shutdown, retorna lote não usado.

Exemplo de implementação de buffer local

class LocalKeyBuffer {
  private keys: string[] = [];
  private readonly refillThreshold = 100;

  constructor(private readonly kgsClient: { fetchBatch: (n: number) => Promise<string[]> }) {}

  async nextKey(): Promise<string> {
    if (this.keys.length <= this.refillThreshold) {
      void this.refill();
    }

    if (this.keys.length === 0) {
      // fallback síncrono em cold start
      this.keys.push(...await this.kgsClient.fetchBatch(1000));
    }

    const key = this.keys.shift();
    if (!key) throw new Error("key_buffer_empty");
    return key;
  }

  private async refill(): Promise<void> {
    const batch = await this.kgsClient.fetchBatch(2000);
    this.keys.push(...batch);
  }
}

Falhas comuns no KGS

1. KGS sem replicação (SPOF).
2. Lotes pequenos demais (muita ida e volta).
3. Sem idempotência na reserva.
4. Sem reconciliação de chave "reservada e nunca usada".

Mecanismo de Redirect: 301 vs 302

Diferença técnica

• 301 (permanente): navegadores/CDNs podem cachear agressivamente.
• 302 (temporário): navegador consulta mais vezes o origin.

Impacto de negócio

Se seu produto depende de analytics por clique, 301 pode reduzir visibilidade porque parte dos acessos não volta para sua borda após cache do cliente.

Estratégia recomendada

• Default: 302 para links com analytics ativo.
• Opcional: 301 para links estáticos sem necessidade de contagem fina.

Regra por plano

Modelagem de Dados

ER simplificado

Esquema SQL (mapeamento)

CREATE TABLE url_mapping (
  short_code        VARCHAR(32) PRIMARY KEY,
  long_url          TEXT NOT NULL,
  user_id           VARCHAR(64) NULL,
  created_at        TIMESTAMP NOT NULL DEFAULT NOW(),
  expires_at        TIMESTAMP NULL,
  is_active         BOOLEAN NOT NULL DEFAULT TRUE,
  redirect_type     SMALLINT NOT NULL DEFAULT 302,
  click_count       BIGINT NOT NULL DEFAULT 0,
  campaign          VARCHAR(128) NULL,
  tags              JSONB NULL,
  CHECK (redirect_type IN (301, 302))
);

CREATE INDEX idx_url_mapping_user_created
  ON url_mapping(user_id, created_at DESC);

CREATE INDEX idx_url_mapping_active_exp
  ON url_mapping(is_active, expires_at);

Esquema para eventos de clique (colunar)

CREATE TABLE click_events (
  event_id String,
  short_code String,
  occurred_at DateTime,
  country LowCardinality(String),
  referrer_domain LowCardinality(String),
  device_type LowCardinality(String),
  browser LowCardinality(String),
  os LowCardinality(String),
  is_bot UInt8,
  ip_hash String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(occurred_at)
ORDER BY (short_code, occurred_at);

Escolha de Banco: SQL vs NoSQL

Padrões de acesso principais

1. short_code -> long_url (lookup ultra frequente).
2. listagem por usuário e data.
3. atualização de estado (active/expired).
4. agregações de analytics (fora do OLTP).

Opção A: SQL (Postgres/MySQL)

Pro: transação forte, índice robusto, operação conhecida.

Contra: escala de leitura global pode exigir réplica/shard cedo.

Opção B: KV/NoSQL (DynamoDB/Cassandra)

Pro: lookup por chave é horizontal por natureza.

Contra: consultas ad-hoc por usuário/campanha ficam piores sem modelagem extra.

Decisão híbrida pragmática

• URL mapping primário: KV ou SQL muito bem indexado (dependendo do time).
• Analytics: armazenamento separado em coluna.
• Search/listagem rica: índice secundário ou materialização.

Estratégia de Cache

Cache é onde se ganha p99 no redirect.

Arquitetura de cache em duas camadas

1. L1 in-process (pequena, por pod).
2. L2 Redis cluster (compartilhado).

Política

• TTL padrão: 1h.
• Hot keys: até 24h com refresh assíncrono.
• Negative cache para 404: TTL curto (30-60s).

Fluxo completo de redirect com cache

async function resolveShortCode(shortCode: string): Promise<string | null> {
  const l1 = lru.get(shortCode);
  if (l1) return l1;

  const l2 = await redis.get(`url:${shortCode}`);
  if (l2) {
    lru.set(shortCode, l2);
    return l2;
  }

  const row = await repo.findActiveByShortCode(shortCode);
  if (!row) {
    await redis.set(`url:missing:${shortCode}`, "1", "EX", 45);
    return null;
  }

  await redis.set(`url:${shortCode}`, row.longUrl, "EX", 3600);
  lru.set(shortCode, row.longUrl);
  return row.longUrl;
}

Estimativa de hit ratio

Com distribuição de acesso típica:

• L1 hit: 20-35%
• L2 hit: 50-65%
• DB hit: 10-20%

Meta operacional realista: hit total > 80%.

Sistema de Analytics

O maior erro nesse tema é gravar analytics síncrono no caminho de redirect.

Regra de ouro

Redirect nunca espera analytics.

Pipeline

Evento de clique

type ClickEvent = {
  eventId: string;
  shortCode: string;
  occurredAt: string;
  ipHash: string;
  userAgent: string;
  referrer: string;
  acceptLanguage?: string;
  edgeRegion: string;
};

Exemplo do coletor assíncrono

export async function publishClick(event: ClickEvent): Promise<void> {
  await kafkaProducer.send({
    topic: "click-events-v1",
    messages: [{ key: event.shortCode, value: JSON.stringify(event) }],
    acks: 1,
  });
}

Enriquecimento em stream

export function enrich(event: ClickEvent) {
  return {
    ...event,
    country: geoip.lookup(event.ipHash)?.country ?? "UNK",
    deviceType: parseDevice(event.userAgent),
    browser: parseBrowser(event.userAgent),
    referrerDomain: safeDomain(event.referrer),
    isBot: botHeuristic(event.userAgent),
  };
}

Queries comuns (ClickHouse)

-- Cliques diários por link
SELECT toDate(occurred_at) AS d, count() AS clicks
FROM click_events
WHERE short_code = 'aZ8k2Pm'
  AND occurred_at >= now() - INTERVAL 30 DAY
GROUP BY d
ORDER BY d;

-- Top países de um link
SELECT country, count() AS clicks
FROM click_events
WHERE short_code = 'aZ8k2Pm'
GROUP BY country
ORDER BY clicks DESC
LIMIT 10;

Exemplo prático de KPI

• CTR por campanha.
• click-to-conversion com join externo.
• detecção de tráfego suspeito por burst.

Aliases Customizados

Alias customizado agrega valor de produto e risco operacional.

Regras de validação

• comprimento: 3 a 32.
• permitido: [a-zA-Z0-9-_].
• blacklist de termos reservados (admin, api, help, login).
• normalização case-insensitive no lookup.

Fluxo de reserva

SQL de inserção com garantia de unicidade

INSERT INTO url_mapping (short_code, long_url, user_id, redirect_type)
VALUES ($1, $2, $3, 302)
ON CONFLICT (short_code) DO NOTHING;

Política de conflito

• retorna 409 conflict quando alias já existe.
• opcional: sugestão de sufixo.

Expiração e Cleanup

Dois modelos se complementam:

1. Lazy expiration: valida no read path.
2. Active cleanup: job assíncrono remove/arquiva vencidos.

Lazy expiration (necessário)

No redirect, se expires_at <= now(), responde 410 Gone e evita redirect.

Active cleanup (higiene)

DELETE FROM url_mapping
WHERE expires_at IS NOT NULL
  AND expires_at < NOW() - INTERVAL '7 days'
  AND is_active = false
LIMIT 50000;

Estratégia recomendada

• marcar como inativo no vencimento.
• manter janela curta para auditoria.
• remover depois da janela conforme política legal.

Rate Limiting

Sem rate limiting, seu produto vira alvo barato para abuso.

Algoritmo: Token Bucket

type BucketState = {
  tokens: number;
  lastRefillMs: number;
};

function refill(state: BucketState, ratePerSec: number, capacity: number, nowMs: number): BucketState {
  const elapsed = (nowMs - state.lastRefillMs) / 1000;
  const add = elapsed * ratePerSec;
  return {
    tokens: Math.min(capacity, state.tokens + add),
    lastRefillMs: nowMs,
  };
}

function consume(state: BucketState, cost = 1): [BucketState, boolean] {
  if (state.tokens >= cost) {
    return [{ ...state, tokens: state.tokens - cost }, true];
  }
  return [state, false];
}

Camadas de limitação

1. Edge (WAF/CDN).
2. API Gateway.
3. Service-level por usuário/chave.
4. Regras especiais para alias customizado e bulk API.

Exemplo de limites por plano

Segurança

URL shortener é vetor comum de abuso. Segurança aqui é funcionalidade de produto.

Vetores principais

1. Phishing em domínio encurtado.
2. Malware distribution.
3. Enumeração de links.
4. Open redirect chaining.
5. Flood de criação automatizada.

Controles recomendados

• reputação de domínio no momento da criação.
• sandbox/verificação para links suspeitos.
• page de aviso intersticial para risco alto.
• hashes de IP (não IP cru) para privacidade em analytics.
• assinatura/HMAC em endpoints internos sensíveis.

Exemplo de validação de URL

export function validateLongUrl(input: string): { ok: boolean; reason?: string } {
  try {
    const u = new URL(input);

    if (!["http:", "https:"].includes(u.protocol)) {
      return { ok: false, reason: "unsupported_protocol" };
    }

    if (!u.hostname || u.hostname.length < 3) {
      return { ok: false, reason: "invalid_host" };
    }

    if (isPrivateAddress(u.hostname)) {
      return { ok: false, reason: "private_address_not_allowed" };
    }

    if (isBlockedDomain(u.hostname)) {
      return { ok: false, reason: "domain_blocked" };
    }

    return { ok: true };
  } catch {
    return { ok: false, reason: "invalid_url" };
  }
}

Enumeração e scraping

Se usar IDs sequenciais sem ofuscação, atacante varre grande parte da base.

Mitigações:

• chave não sequencial (snowflake + encode + salt/permute).
• detecção de padrão de acesso sequencial.
• rate limit agressivo em padrão suspeito.

Distribuição Global

Para produto global, 50ms p99 sem edge é improvável.

Estratégia multi-região

Leitura e escrita

• Escrita: pode centralizar em região primária no início.
• Leitura: sempre local/regional quando possível.
• Replicação: eventual para read replicas globais.

Caching na borda

Para links muito quentes, CDN pode responder redirect sem tocar app.

Cuidado: isso impacta nível de detalhe de analytics por clique.

Orçamento de latência (exemplo)

TLS + edge: 10-15ms
LB + app routing: 2-5ms
Redis lookup: 1-3ms
Fallback DB (cache miss): 8-20ms
Response write: 2-5ms
Total p99 (cache hit): 20-35ms

Confiabilidade e Tolerância a Falhas

Análise de pontos únicos de falha

1. Redis único.
2. DB primary sem failover testado.
3. Kafka sem estratégia de retry/DLQ.
4. KGS sem redundância.

Políticas práticas

• réplicas para Redis e DB com failover automático.
• circuit breaker para dependências não críticas.
• DLQ para eventos inválidos de analytics.
• replay de tópicos para recomputar agregados.

Exemplo de circuit breaker simples

class CircuitBreaker {
  private failures = 0;
  private openUntil = 0;

  constructor(private readonly threshold = 5, private readonly coolDownMs = 5000) {}

  async run<T>(fn: () => Promise<T>, fallback: () => Promise<T>): Promise<T> {
    const now = Date.now();
    if (now < this.openUntil) return fallback();

    try {
      const res = await fn();
      this.failures = 0;
      return res;
    } catch {
      this.failures += 1;
      if (this.failures >= this.threshold) {
        this.openUntil = now + this.coolDownMs;
      }
      return fallback();
    }
  }
}

Graceful degradation

• se analytics cair: redirect continua.
• se geolocation cair: evento marca country UNK.
• se recomendação de alias cair: criação continua sem sugestão.

Observabilidade mínima obrigatória

• RED metrics (rate, errors, duration) por endpoint.
• p95/p99 do redirect.
• hit ratio de cache L1/L2.
• backlog e lag de Kafka.
• erro por categoria de validação.

Dicas de Entrevista

Roteiro de 45 minutos

1. 5-7 min: requisitos + escala.
2. 5-8 min: cálculos de ordem de grandeza.
3. 8-10 min: arquitetura macro.
4. 10-12 min: deep dive em chave, redirect e cache.
5. 5-8 min: confiabilidade, segurança e trade-offs.
6. 3-5 min: fechamento com evolução e riscos.

Frases que mostram senioridade

• "Vou separar write path de read path para escalar custo e latência de forma independente."
• "Redirect não pode depender de analytics síncrono no caminho quente."
• "Consistência forte é para mapeamento; eventual é aceitável para contadores."
• "Vou assumir 7 caracteres para folga de espaco de chave e crescimento."

O que entrevistador procura

1. Clareza de trade-off.
2. Prioridade correta no caminho quente.
3. Pensamento operacional (falha, observabilidade, abuso).
4. Evolução incremental sem reescrever tudo.

Anti-Patterns para Evitar

1) Único banco relacional para tudo

Problema: mistura OLTP de redirect com analítico pesado.

Correto: separar mapeamento de URL e analytics em stores próprios.

2) Gravar evento de clique antes de redirecionar

Problema: aumenta latência e propaga falha de analytics para UX.

Correto: publicar evento async e devolver redirect primeiro.

3) Gerar chave random com check síncrono em alta escala

Problema: colisão cresce com volume, custo de retry aumenta.

Correto: snowflake/base62 ou KGS para previsibilidade.

4) Ignorar validação de URL

Problema: vira plataforma de abuso rapidamente.

Correto: validação de protocolo, host, reputação e políticas de risco.

5) Não definir políticas de expiração

Problema: crescimento de custo e acurácia ruim em dados antigos.

Correto: lazy expiration + cleanup ativo + retention clara.

6) Usar 301 para tudo sem discutir analytics

Problema: perde observabilidade de clique em alguns cenários de cache.

Correto: 302 por padrão quando analytics importa.

7) Sem estratégia anti-enumeração

Problema: scraping massivo de links.

Correto: chave não previsível + rate limit + detecção de padrão.

Conclusão

Um URL shortener parece pequeno no produto, mas é grande na engenharia.

A diferença entre um sistema didático e um sistema de produção está em três pontos:

1. Lookup de redirect extremamente rápido com cache bem desenhado.
2. Separação forte entre caminho quente e pipelines assíncronos.
3. Controles operacionais para abuso, falha e crescimento.

Se você cobrir requisitos, cálculos, algoritmo de chave, cache, analytics e confiabilidade com clareza de trade-off, você entrega uma resposta de nível senior em entrevista e um desenho viável para produção.

Referências

• Bitly
• TinyURL
• Redis Documentation
• Kafka Documentation
• ClickHouse Documentation
• Cloudflare Blog
• AWS Architecture Blog
• Google SRE Book

Referência Rápida

Arquitetura em 30 segundos

• Edge (GeoDNS + CDN + WAF)
• Redirect Service (cache-first)
• URL Creation Service (KGS/snowflake)
• URL Mapping Store
• Redis (L1/L2 strategy)
• Kafka + Stream + ClickHouse para analytics

Números-chave

Decisões principais

Checklist de entrevista

• Clarificou requisitos funcionais e não funcionais
• Fez cálculos de QPS, storage e keyspace
• Desenhou arquitetura com read/write path separado
• Explicou algoritmo de chave com trade-off
• Tratou cache, p99 e fallback
• Separou analytics do caminho quente
• Cobriu segurança e anti-abuso
• Cobriu confiabilidade, failover e observabilidade
• Fechou com riscos e evolução

Apêndice A: Exemplo completo de URL Creation Service

import { randomUUID } from "crypto";

type CreateInput = {
  longUrl: string;
  userId?: string;
  customAlias?: string;
  expiresAt?: string;
  redirectType?: 301 | 302;
  campaign?: string;
  tags?: string[];
};

type CreateOutput = {
  shortCode: string;
  shortUrl: string;
  createdAt: string;
};

export class UrlCreationService {
  constructor(
    private readonly keyProvider: { next: () => Promise<string> },
    private readonly repo: {
      insert: (row: {
        shortCode: string;
        longUrl: string;
        userId: string | null;
        expiresAt: string | null;
        redirectType: 301 | 302;
        campaign: string | null;
        tags: string[];
      }) => Promise<boolean>;
      exists: (shortCode: string) => Promise<boolean>;
    },
  ) {}

  async create(input: CreateInput): Promise<CreateOutput> {
    const validation = validateLongUrl(input.longUrl);
    if (!validation.ok) {
      throw new Error(validation.reason ?? "invalid_url");
    }

    const shortCode = input.customAlias
      ? await this.reserveAlias(input.customAlias)
      : await this.generateSystemCode();

    const createdAt = new Date().toISOString();
    const ok = await this.repo.insert({
      shortCode,
      longUrl: input.longUrl,
      userId: input.userId ?? null,
      expiresAt: input.expiresAt ?? null,
      redirectType: input.redirectType ?? 302,
      campaign: input.campaign ?? null,
      tags: input.tags ?? [],
    });

    if (!ok) {
      throw new Error("insert_failed");
    }

    return {
      shortCode,
      shortUrl: `https://s.ua/${shortCode}`,
      createdAt,
    };
  }

  private async reserveAlias(alias: string): Promise<string> {
    const normalized = alias.trim();

    if (!/^[a-zA-Z0-9_-]{3,32}$/.test(normalized)) {
      throw new Error("invalid_alias");
    }

    if (isReservedAlias(normalized)) {
      throw new Error("reserved_alias");
    }

    const exists = await this.repo.exists(normalized);
    if (exists) throw new Error("alias_conflict");

    return normalized;
  }

  private async generateSystemCode(): Promise<string> {
    for (let i = 0; i < 5; i++) {
      const code = await this.keyProvider.next();
      const exists = await this.repo.exists(code);
      if (!exists) return code;
    }

    // fallback defensivo
    return randomUUID().replace(/-/g, "").slice(0, 8);
  }
}

function isReservedAlias(alias: string): boolean {
  const reserved = new Set([
    "api",
    "admin",
    "help",
    "login",
    "status",
    "docs",
    "metrics",
  ]);
  return reserved.has(alias.toLowerCase());
}

Apêndice B: Exemplo de schema Redis keys

url:{shortCode} -> JSON mapping (TTL 3600)
url:missing:{shortCode} -> "1" (TTL 45)
rl:user:{userId}:create -> token bucket state
rl:ip:{ip}:redirect -> token bucket state
stats:counter:{shortCode}:{yyyyMMdd} -> integer

Estratégia de versionamento de chave

v1:url:{shortCode}
v2:url:{shortCode}

Facilita migração de payload sem invalidação massiva arriscada.

Apêndice C: Exemplo de detecção de anomalia simples

type WindowCounter = {
  minute: number;
  clicks: number;
};

export function isSuspiciousBurst(windowSeries: WindowCounter[]): boolean {
  if (windowSeries.length < 10) return false;

  const last = windowSeries.at(-1)?.clicks ?? 0;
  const prev = windowSeries.slice(-10, -1).map((x) => x.clicks);
  const avg = prev.reduce((a, b) => a + b, 0) / prev.length;

  return last > avg * 20 && last > 500;
}

Quando true, ativa regras:

• desafio adicional.
• throttling por ASN/região.
• flag para revisão automática.

Apêndice D: Evolução por fases

Fase 1 (0 -> 1)

• 1 região.
• SQL + Redis.
• analytics em fila simples.
• sem alias customizado.

Fase 2 (1 -> 10)

• read replicas.
• pipeline de enrichment.
• dashboard de campanha.
• controles de abuso mais fortes.

Fase 3 (10 -> 100)

• multi-região de leitura.
• edge caching seletivo.
• segmentação por plano com SLA.
• observabilidade madura com SLO formal.

Apêndice E: SLOs e Error Budget

SLOs sugeridos

• Redirect availability: 99.99% mensal.
• Redirect latency p99: <= 50ms.
• URL create p99: <= 200ms.
• Data freshness de analytics near real-time: <= 60s p95.

Error budget mensal (99.99)

43,200 minutos por mês
0.01% de budget = 4.32 minutos de indisponibilidade

Se estourar budget:

1. congela feature de risco alto.
2. prioriza hardening operacional.
3. revisa causa raiz e runbooks.

Apêndice F: Runbook de incidente (resumo)

Incidente: aumento de 404 no redirect

1. Verificar deploy recente no Redirect Service.
2. Checar hit ratio Redis e erros de conexão.
3. Verificar replicação da base de mapeamento.
4. Rodar query de amostra por shortCode afetado.
5. Se necessário, rollback do deploy.
6. Abrir postmortem com timeline e ações.

Incidente: fila de analytics atrasada

1. Confirmar lag por partição no Kafka.
2. Escalar consumers horizontalmente.
3. Verificar gargalo no sink (ClickHouse).
4. Reduzir enriquecimento pesado temporariamente.
5. Garantir redirect path intacto.

Apêndice G: Exemplo de contrato de evento versionado

{
  "eventVersion": "1.0",
  "eventType": "url.click",
  "eventId": "evt_01J8YH8S0ZJYV9P8R3P7A5Y2Q1",
  "occurredAt": "2026-02-15T22:10:11.124Z",
  "shortCode": "aZ8k2Pm",
  "request": {
    "edgeRegion": "sa-east-1",
    "referrer": "https://news.example.com",
    "userAgent": "Mozilla/5.0 ..."
  },
  "privacy": {
    "ipHash": "sha256:6c57..."
  }
}

Apêndice H: Trade-offs finais resumidos

Este artigo serve como blueprint de referência para entrevistas e para implementação real em etapas.