LinkGuardião

Visão geral

Sistema de encurtamento de URLs com autenticação, links protegidos por senha, expiração configurável e analytics de acesso processado de forma assíncrona.

O problema é mais sofisticado do que um encurtador comum: controlar quem acessa um link, por quanto tempo ele permanece válido e como esse acesso é monitorado sem degradar a latência do redirecionamento.

Arquitetura

Backend em camadas com um componente assíncrono separado para analytics via SQS + Lambda. A decisão evita complexidade prematura e aplica arquitetura distribuída só onde ela paga.

• LinkGuardiao.Api Composição da aplicação, controllers, middlewares, health checks e integração com AWS Lambda.
• LinkGuardiao.Application DTOs, entidades, contratos, validações, serviços de aplicação e métricas.
• LinkGuardiao.Infrastructure Implementações para DynamoDB, SQS, Redis, JWT e segurança.
• LinkGuardiao.Infrastructure.PostgreSQL Implementação alternativa de persistência relacional com EF Core.
• LinkGuardiao.AnalyticsConsumer Consumer dedicado para a fila de analytics.

Fluxo de redirecionamento e analytics

1. O usuário autenticado cria um link; a API valida a URL, verifica o limite diário, aplica hash na senha (se houver) e persiste no storage configurado.
2. Alguém acessa o link curto e o backend resolve o destino.
3. Se o link for protegido, a UI consulta o endpoint público para saber se existe senha e solicita um access grant temporário.
4. O redirect oficial valida o grant, enfileira a mensagem de analytics no SQS e responde imediatamente com o redirecionamento.
5. A Lambda consumer processa a mensagem fora do caminho crítico, grava o acesso e incrementa o contador de cliques.
6. O dashboard consulta as estatísticas agregadas e exibe cliques por data, navegador e top IPs.

Pontos fortes

• Decisão arquitetural correta de tirar o analytics do fluxo síncrono de redirect — troca consciente de consistência forte por latência.
• Suporte a dois modelos de persistência (DynamoDB e PostgreSQL), mostrando abstração real de storage.
• Mensageria real com SQS e Lambda consumer, incluindo retry e DLQ.
• Infraestrutura como código em CDK, incluindo WAF, alarmes e dashboard.
• Segurança acima da média: rate limiting, JWT com issuer/audience, PBKDF2, CORS restrito, security headers e access grant temporário.
• Testes automatizados distribuídos entre Application, API e persistência PostgreSQL.

Limites e decisões conscientes

O que este projeto não faz, e por quê. Descrever isso com precisão vale mais do que exagerar o escopo.

• Não existe uma camada Domain separada da Application — as entidades são modelos anêmicos, sem comportamento rico.
• Sem aggregates, value objects, domain events explícitos ou bounded contexts formalizados.
• O uso de Event Driven é pontual (apenas o pipeline de analytics), não sistêmico.
• O analytics é eventualmente consistente: as estatísticas podem aparecer alguns instantes depois do clique.