// Phase 3 of 4 — SDE 2 Trail

Think Like Cave Architect

Ugh. Week 9 to Week 12 now. No more small tool — now design whole cave-system. URL Shortener, Rate Limiter, Chat App, News Feed, Database choice, Sharding, Replication. Then take real AgentOS and make it stronger — proof-of-strength for interview fire.

Week 9 · Simple System

Design: URL Shortener

Turn long ugly link into short cave-mark, like bit.ly/xk9F2. Classic first design-hunt — small enough to finish, big enough teach real lesson.

Core Requirement

  • Given long URL, return short code (e.g. 7 char).
  • Given short code, redirect to original long URL fast.
  • High read : write ratio (~100:1) — many click, few create.

Key Design Decision

  • Encoding: Base62 (a-z, A-Z, 0-9) of auto-increment ID, or random-generate + collision check.
  • Storage: Key-Value store (Redis/DynamoDB) — short-code → long-URL mapping.
  • Cache: Cache hot short-codes in Redis, most click hit small % of link (80/20 rule).
// Base62 encode — turn auto-increment ID into short code
const CHARS = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
function encode(id) {
  let code = '';
  while (id > 0) {
    code = CHARS[id % 62] + code;
    id = Math.floor(id / 62);
  }
  return code.padStart(7, 'a');
}
encode(125); // e.g. "aaaaaab" style short code
Cave wisdom: Interviewer want hear you discuss: capacity estimate (how many URL/day?), read-heavy caching, ID-collision handling, and custom-alias feature. Draw box: Client → Load Balancer → App Server → Cache → DB.
Week 9 · Simple System

Design: Rate Limiter

Too many hunter attack cave gate at once — rate limiter stop after X request per time-window, protect cave from overload or abuse.

▶ Live Hunt: Token Bucket Algorithm

Bucket capacity: 5 tokens
Bucket start full (5 token). Each request cost 1 token. Press "Send Request" to try.

Common Algorithm

  • Token Bucket: bucket refill at fixed rate, request consume token, allow burst up to bucket size.
  • Fixed Window: count request per fixed time-block (e.g. per minute), simple but allow edge-burst.
  • Sliding Window Log: track exact timestamp of each request, accurate but more memory.

Where Store Counter

Redis (with TTL / atomic INCR) common choice — fast, shared across multiple app server instance. Local in-memory counter only work for single-server, not distributed system.

Cave wisdom: Always ask interviewer: "Rate limit per user? Per IP? Per API key?" and "What happen when limit hit — reject with 429, or queue?" Shows deep thinking.
Week 10 · Bigger System

Design: Chat App

Two hunter talk across far cave, message must arrive fast, in order, even if hunter offline for while.

Core Requirement

  • Real-time message delivery (low latency).
  • Message persist — offline user get message when back online.
  • Read receipt, typing indicator (nice-to-have).
  • Support 1-on-1 and group chat.

Key Design Decision

  • Connection: WebSocket for real-time push (not polling — too slow, too wasteful).
  • Fan-out: Message Queue between sender and multiple recipient (group chat).
  • Storage: NoSQL (Cassandra-style) — chat history is write-heavy, append-only, partition by conversation-id.
Cave wisdom: Draw flow: Sender → WebSocket Gateway → Message Queue → Fan-out Service → Recipient WebSocket (if online) + DB (always, for offline sync).
Week 10 · Bigger System

Design: News Feed

Hunter follow many other hunter, want see all their new stone-post in one scroll, newest first, without wait long.

Fan-out on Write vs Read

Fan-out on Write: when post created, immediately push to all follower's feed-cache. Fast read, but expensive if celebrity has million follower.

Fan-out on Read: feed built at request-time, pull latest post from everyone you follow. Slower read, but no wasted write for inactive user.

Hybrid Approach (Real World)

Most big platform mix both — normal user get fan-out-on-write (fast), celebrity account use fan-out-on-read (avoid write-storm). This exact kind of trade-off talk is what SDE 2 interview want hear.

Cave wisdom: Also discuss: ranking algorithm (chronological vs engagement-based), pagination (cursor-based better than offset for infinite scroll), and caching hot feed in Redis.
Week 10

Message Queue (Kafka / RabbitMQ Concept)

Instead hunter hand stone direct to other hunter (must both free same moment), drop stone in shared basket. Other hunter pick up basket whenever ready. Decouple sender from receiver.

Why Use Queue

  • Decoupling: producer and consumer don't need know each other, don't need be online same time.
  • Buffering: absorb traffic spike, consumer process at own pace.
  • Retry/reliability: failed message can requeue, not lost.

Kafka vs RabbitMQ (concept)

Kafka: log-based, message kept for replay, great for high-throughput event stream (analytics, activity log).

RabbitMQ: traditional message broker, message removed after ack, great for task-queue / job processing.

// Conceptual producer/consumer — not tied to specific library
// Producer side
queue.publish('new_message_topic', { chatId, senderId, text });

// Consumer side (fan-out service)
queue.subscribe('new_message_topic', async (event) => {
  const recipients = await getRecipients(event.chatId);
  for (const r of recipients) pushToClient(r, event);
});
Cave wisdom: Your Nexus-a2a project already touch agent-to-agent communication concept — Message Queue idea directly related. Good bridge to talk about in interview!
Week 11 · Database Design

SQL vs NoSQL Choice

Two style of storage-cave. SQL — strict shelf, every stone same shape, strong relationship rule. NoSQL — flexible basket, stone can differ shape, trade strict-rule for speed/scale.

AspectSQL (Relational)NoSQL
SchemaFixed, strictFlexible, dynamic
RelationshipStrong (JOIN, FK)Weak / denormalized
Scale styleVertical mainlyHorizontal, built-in
ConsistencyACID (strong)Often eventual
Good forTransaction, complex queryHigh-volume, flexible data
Cave wisdom: Don't say "NoSQL always better for scale" — that's shallow. Say: "I'd pick SQL for order/payment system needing ACID transaction, NoSQL for chat history or activity feed needing horizontal scale." Show judgement, not memorized rule.
Week 11

Sharding

One storage-cave too full, can't fit more stone. Split data across many smaller cave (shard), each hold only piece of whole.

▶ Live Hunt: Hash-Based Sharding

Press "Add User" — watch hash(user_id) % 3 decide which shard hold their data.

Sharding Strategy

  • Hash-based: hash(key) % N shards. Even spread, but resharding painful (need consistent hashing to ease this).
  • Range-based: shard by value range (e.g. user A-M, N-Z). Simple, but risk hot-shard if data skew.

Sharding Challenge

Cross-shard JOIN become hard/expensive. Resharding (adding new shard) need data migration. Choose shard-key carefully — wrong choice cause "hot shard" bottleneck.

Cave wisdom: Shard-key choice is THE critical decision. Pick key that's used in most query, and spread data evenly — e.g. user_id often good, but "country" bad if 90% user from one country.
Week 11

Replication

Keep copy of same cave-data in multiple place. If one cave collapse (server down), other copy still stand — data survive.

Master-Replica (Primary-Secondary)

All WRITE go to Master. Master copy change to Replica(s). READ can spread across Replicas — reduce load on Master, improve read-throughput.

Sync vs Async Replication

Synchronous: Master wait Replica confirm write before ack client. Strong consistency, slower write.

Asynchronous: Master ack immediately, Replica catch up later. Fast write, small risk of data-lag/loss on crash.

Cave wisdom: Sharding = split data (more capacity). Replication = copy data (more reliability + read-speed). Real big system almost always use BOTH together.
AgentOS Grow · Week 12

Take AgentOS from Project to Proof-of-Strength

This week not learn new tool — this week PROVE tool already learned. Real interview love real project more than any tutorial-clone. AgentOS (Caretaker + Nexus-a2a) already strong seed — now make it bloom.

Pick One Real Feature to Add

  • Caretaker: improve ChromaDB search relevance (known weak spot) — try re-ranking, hybrid search, or better embedding strategy.
  • Nexus-a2a: add new agent-communication pattern, or a monitoring/observability hook for agent message flow.
  • Add a small system-design element you just learned — e.g. rate-limit Caretaker's API, or shard memory storage by agent-id.

README Must Include

  • One-line pitch: what problem AgentOS solve.
  • Architecture diagram — Caretaker, Nexus-a2a, OS Core (planned), how they connect.
  • Setup instruction (clean, tested, copy-paste-able).
  • Design decision section — "why I choose X over Y" (shows architect thinking).
// Example README skeleton structure
## AgentOS
> Universal memory + agent-to-agent communication layer for AI agent system.

## Architecture
[diagram: Caretaker (memory) <-> Nexus-a2a (comm) <-> OS Core (planned, Rust)]

## Why These Choice
- ChromaDB for vector search: chosen for local-first, no external dependency
- FastAPI for Nexus-a2a: async support fit agent-to-agent latency need

## Setup
git clone ... && uv sync && uv run start
Cave wisdom: In interview, when asked "tell me about project you own," THIS is your answer. Walk through: problem → design choice → trade-off → what you'd improve next. This IS the SDE 2 signal company look for.