Requirements

Functional Requirements:

 - Usuários podem postar tweets

 - Usuários podem seguir outros usuários

 - Usuários podem ver feed

Non-Functional Requirements:

 - Sistema deve suportar 1 milhão de usuários

 - Latência < 200ms

 - 99.9% de disponibilidade

 - Escalável horizontalmente

Capacity Estimation

 - 1 milhão de usuários ativos/dia

 - 100 tweets/segundo (TPS)

 - Armazenamento: 100GB/dia

 - Largura de banda: 50MB/s

API Design

 POST  /tweets       // Criar tweet

 GET  /tweets/:id     // Obter tweet

 GET  /feed        // Ver feed

 POST  /users/:id/follow  // Seguir usuário

 DELETE /tweets/:id     // Deletar tweet

High-Level Design

 [Cliente]

   ↓

 [Load Balancer]

   ↓

 [API Servers] (múltiplos)

   ↓

 [Cache - Redis]

   ↓

 [Database - PostgreSQL]

   ↓

 [Message Queue - Kafka]

   ↓

 [Notification Service]

Database Design

 Users Table:

 - id (PK)

 - username

 - email

 - created_at

 - created_at

 Tweets Table:

 - id (PK)

 - user_id (FK)

 Tweets Table:

 - id (PK)

 - user_id (FK)

 - content

 - created_at

 Followers Table:

 - follower_id

 - following_id

Detailed Component Design

 Deep dive em 2-3 componentes críticos.

 Exemplo: Cache Strategy

 - O que cachear? (Tweets populares, feeds)

 - Quanto tempo? (TTL = 1 hora)

 - Quando invalidar? (Quando novo tweet é postado)

 - Fallback? (Se cache cair, vai pro BD)

 Exemplo: Message Queue

 - Por quê? (Para desacoplar Tweet Service de Notification Service)

 - Qual? (Kafka, RabbitMQ)

 - Como funciona? (Producer → Queue → Consumer)