面试题目分析
    │
    ├─ 题目是否专门设计"搜索系统"？
    │   │
    │   ├─ YES → 深入实现搜索（不能直接用 Elasticsearch）
    │   │   └─ 需要实现：Inverted Index, Tokenization, Ranking 等
    │   │
    │   └─ NO → 继续判断...
    │
    ├─ 面试官是否明确禁止使用 Elasticsearch/搜索引擎？
    │   │
    │   ├─ YES → 深入实现搜索
    │   │   └─ 需要自己实现核心搜索功能
    │   │
    │   └─ NO → 继续判断...
    │
    ├─ 搜索是否是系统的核心功能（>50% 的讨论时间）？
    │   │
    │   ├─ YES → 深入实现搜索
    │   │   └─ 即使可以用 Elasticsearch，也要深入讨论其原理
    │   │
    │   └─ NO → 可以用 Elasticsearch 快速带过
    │       └─ 搜索只是系统的一个功能模块
    │
    └─ 题目类型判断
        │
        ├─ "Design Facebook Search" → 深入实现
        ├─ "Design Google Search" → 深入实现
        ├─ "Design Post Search" → 深入实现
        │
        ├─ "Design Ticketmaster" → Elasticsearch 快速带过
        ├─ "Design Uber" → Elasticsearch 快速带过（如果有搜索）
        ├─ "Design Instagram" → Elasticsearch 快速带过（如果有搜索）
        └─ "Design E-commerce" → Elasticsearch 快速带过（如果有搜索）

核心思想：从 keyword → documents，而不是 document → keywords
Core Idea: Map keyword → documents, not document → keywords

数据结构：
Data Structure:
{
  "keyword1": [docId1, docId2, docId3, ...],
  "keyword2": [docId4, docId5, ...],
  ...
}

存储选择：
Storage Options:
- Redis: 内存存储，速度快，但需要考虑持久化
  In-memory storage, fast, but need to consider persistence
- MemoryDB: Redis + 持久化
  Redis + persistence
- 分布式存储：按 keyword hash 分片
  Distributed storage: shard by keyword hash

功能：将文本分解为可搜索的关键词
Function: Break text into searchable keywords

处理步骤：
Processing Steps:
1. 文本预处理：转小写、去除标点
   Text preprocessing: lowercase, remove punctuation
2. 分词：按空格分割
   Tokenization: split by spaces
3. 去停用词（可选）：the, a, an, etc.
   Remove stop words (optional): the, a, an, etc.
4. 词干提取（可选）：running → run
   Stemming (optional): running → run

示例：
Example:
"Taylor Swift Concert" 
→ ["taylor", "swift", "concert"]

单关键词：直接查 inverted index

多关键词（AND）：
- 取交集：intersect(postIds for "Taylor", postIds for "Swift")
- 优化：从最小的 list 开始 intersect

多关键词（OR）：
- 取并集：union(all postIds)

短语查询：
- Bigrams/Shingles: "Taylor Swift" → ["taylor swift"]
- 先查 bigram index，再 filter 验证

按时间排序：
- 使用 Redis List，append 时按时间顺序
- 查询时取最后 N 个元素

按点赞数排序：
- 使用 Redis Sorted Set
- Score = like count
- 查询时用 ZREVRANGE 取 top N

混合排序：
- 维护多个 index（时间 index + 点赞数 index）
- 根据用户选择查询对应的 index

Post Creation Flow:
1. User creates post → Post Service
2. Post Service → Ingestion Service
3. Ingestion Service:
   - Tokenize post content
   - For each keyword:
     - Add postId to Creation Index (Redis List)
     - Add postId to Likes Index (Redis Sorted Set, score=0)
4. Store post metadata in DB

Like Event Flow:
1. User likes post → Like Service
2. Like Service → Ingestion Service
3. Ingestion Service:
   - For each keyword in the post:
     - Update score in Likes Index (ZINCRBY)

Search Flow:
1. User searches "Taylor Swift" sorted by likes
2. Tokenize query → ["taylor", "swift"]
3. Query Likes Index:
   - Get postIds for "taylor" (sorted by likes)
   - Get postIds for "swift" (sorted by likes)
   - Intersect the two lists
4. Return top N results

问题：某些关键词（如 "the", "a"）可能有百万级 postIds

解决方案：
- 限制每个 keyword 的 postId list 大小（如 top 10k）
- 使用 Bloom Filter 快速判断是否存在
- 对于超热门关键词，使用概率数据结构

冷热数据分离：
- Hot keywords → Redis (内存)
- Cold keywords → S3/Blob Storage (磁盘)
- 定期 batch job 迁移冷数据

分片策略：
- 按 keyword hash 分片到多个 Redis 实例
- 减少单个实例的压力

批量处理：
- 使用 Kafka 缓冲写入
- Batch updates 到 Redis
- 异步处理，不阻塞主流程

Like 事件优化：
- 使用 Two-Stage Architecture
- 只在里程碑更新（1, 2, 4, 8, 16... likes）
- 查询时再获取精确的 like count

查询结果缓存：
- Cache key: "search:{keyword}:{sort}:{page}"
- TTL: 根据数据更新频率设置
- 使用 CDN 缓存热门查询

Index 缓存：
- 热门 keyword 的 postId list 保持在内存
- LRU eviction policy

在 Requirements 阶段：
During Requirements phase:
- "Users should be able to search for events by keyword"
- 明确搜索的范围和排序需求
  Clarify search scope and sorting requirements

"对于搜索功能，我会使用 Elasticsearch 作为专门的搜索数据库。
"For search functionality, I'll use Elasticsearch as a dedicated search database.

原因：
Reasons:
1. Elasticsearch 专为全文搜索优化，使用 Inverted Index
   Elasticsearch is optimized for full-text search, uses Inverted Index
2. 支持复杂的查询（fuzzy search, phrase search）
   Supports complex queries (fuzzy search, phrase search)
3. 可以处理高并发查询
   Can handle high concurrent queries
4. 支持多种排序方式
   Supports multiple sorting methods

架构：
Architecture:
- PostgreSQL (主数据库) → CDC → Elasticsearch (搜索索引)
  PostgreSQL (main DB) → CDC → Elasticsearch (search index)
- Search Service 查询 Elasticsearch
  Search Service queries Elasticsearch
- 结果返回给用户
  Results returned to users"

"数据同步：
- 使用 CDC (Change Data Capture) 实时同步
- 或者使用 Kafka 作为中间层
- 确保 Elasticsearch 索引与主数据库一致"

"优化策略：
1. 缓存热门查询结果（Redis）
2. CDN 缓存（如果搜索结果不个性化）
3. Elasticsearch 集群水平扩展"

面试开始时的对话：

Candidate: "Before I start, I want to clarify - are we allowed to use 
            search engines like Elasticsearch, or should I design the 
            search functionality from scratch?"

Interviewer: "You can use Elasticsearch" 
→ 快速带过，重点放在其他功能

Interviewer: "No, you need to build it from scratch"
→ 深入实现，重点讨论搜索原理

题目名称包含 "Search":
→ 默认需要深入实现
→ 如果面试官说可以用 Elasticsearch，再调整

题目名称是其他系统（Ticketmaster, Uber, etc.）:
→ 默认可以用 Elasticsearch 快速带过
→ 如果面试官禁止，再深入实现

深入实现搜索（45-60分钟面试）:
- Requirements: 5分钟
- Core Entities & API: 5分钟
- High-Level Design (Inverted Index): 15分钟
- Deep Dives (优化、扩展): 20-30分钟
- 总结: 5分钟

Elasticsearch 快速带过（45-60分钟面试）:
- 搜索需求识别: 2分钟
- Elasticsearch 方案: 3分钟
- 数据同步说明: 2分钟
- 优化策略: 2分钟
- **总共 10 分钟内完成搜索部分**
- 剩余时间讨论其他核心功能

面试开始 → 看题目名称
Interview starts → Check problem name
    │
    ├─ 包含 "Search" → 准备深入实现
    │   Contains "Search" → Prepare deep implementation
    │   └─ 问面试官："Can I use Elasticsearch?"
    │       Ask interviewer: "Can I use Elasticsearch?"
    │       ├─ No → 深入实现 Inverted Index
    │       │       Deep implementation of Inverted Index
    │       └─ Yes → 可以讨论原理，但用 Elasticsearch
    │               Can discuss principles, but use Elasticsearch
    │
    └─ 不包含 "Search" → 准备快速带过
        Doesn't contain "Search" → Prepare quick pass
        └─ 提到搜索时直接说："I'll use Elasticsearch with CDC"
            When mentioning search: "I'll use Elasticsearch with CDC"
            └─ 如果面试官追问 → 简单说明原理
                If interviewer asks → Briefly explain principles
            └─ 如果面试官禁止 → 切换到深入实现模式
                If interviewer forbids → Switch to deep implementation mode

"对于搜索功能，我需要实现一个 Inverted Index。
"For search functionality, I need to implement an Inverted Index.

核心思路是：
Core approach:
1. 建立 keyword → [postIds] 的映射
   Build keyword → [postIds] mapping
2. 使用 Redis 存储，List 用于时间排序，Sorted Set 用于点赞数排序
   Use Redis: List for time sorting, Sorted Set for like count sorting
3. 写入时 tokenize 内容，更新所有相关 keyword 的 index
   On write: tokenize content, update all related keyword indices
4. 查询时取交集/并集，然后排序返回
   On query: intersect/union, then sort and return

让我详细设计一下写入和查询的流程..."
Let me design the write and query flows in detail..."

"对于搜索功能，我会使用 Elasticsearch 作为专门的搜索数据库。
"For search functionality, I'll use Elasticsearch as a dedicated search database.

架构上：
Architecture:
- 主数据库（PostgreSQL）通过 CDC 同步到 Elasticsearch
  Main DB (PostgreSQL) syncs to Elasticsearch via CDC
- Search Service 查询 Elasticsearch 返回结果
  Search Service queries Elasticsearch and returns results
- 使用 Redis 缓存热门查询，CDN 缓存静态结果
  Use Redis to cache popular queries, CDN to cache static results

这样可以满足低延迟搜索的需求。现在让我继续设计系统的其他核心功能..."
This meets low-latency search requirements. Now let me continue designing other core features..."