Trade-offs & Design Decisions

1// ============================================
2// Trade-offs in Action — Real Design Decisions
3// ============================================
4
5// ---------- Trade-off 1: Normalization vs Denormalization ----------
6
7// ❌ NORMALIZED (optimized for writes, slow reads — many JOINs)
8// Tables: users, posts, comments, likes
9// To show a feed, you need 4+ JOIN queries
10
11const normalizedQuery = `
12  SELECT p.id, p.content, u.name, u.avatar,
13         COUNT(DISTINCT l.id) as likes,
14         COUNT(DISTINCT c.id) as comments
15  FROM posts p
16  JOIN users u ON p.user_id = u.id
17  LEFT JOIN likes l ON l.post_id = p.id
18  LEFT JOIN comments c ON c.post_id = p.id
19  WHERE p.user_id IN (SELECT followed_id FROM follows WHERE follower_id = ?)
20  GROUP BY p.id
21  ORDER BY p.created_at DESC
22  LIMIT 20;
23  -- This query is SLOW at scale (multiple JOINs, subquery)
24`;
25
26// ✅ DENORMALIZED (optimized for reads, more work on writes)
27// Pre-computed feed table: each row has everything needed to render
28
29const denormalizedFeedEntry = {
30  postId: "post_123",
31  authorName: "Jane Doe",           // Copied from users table
32  authorAvatar: "cdn.com/jane.jpg", // Copied from users table
33  content: "Hello world!",
34  likeCount: 42,                    // Pre-computed counter
35  commentCount: 7,                  // Pre-computed counter
36  topComments: [                    // Pre-fetched top 3 comments
37    { user: "Bob", text: "Great post!" },
38  ],
39  createdAt: "2024-01-15T10:30:00Z",
40};
41
42// Trade-off: When Jane changes her avatar, we need to update
43// every feed entry that references her — more write complexity
44// but reads are now a simple single-table lookup.
45
46// ---------- Trade-off 2: Sync vs Async Processing ----------
47
48// ❌ SYNCHRONOUS: User waits for everything
49async function handleOrderSync(order) {
50  await validateOrder(order);           // 50ms
51  await chargePayment(order);           // 200ms
52  await updateInventory(order);         // 100ms
53  await sendConfirmationEmail(order);   // 300ms
54  await notifyWarehouse(order);         // 150ms
55  await updateAnalytics(order);         // 100ms
56  // Total: ~900ms — user waits for ALL of this!
57  return { status: 'completed' };
58}
59
60// ✅ ASYNCHRONOUS: User gets immediate response, rest happens in background
61async function handleOrderAsync(order) {
62  // Only do what the user MUST wait for
63  await validateOrder(order);           // 50ms
64  const paymentResult = await chargePayment(order); // 200ms
65
66  if (paymentResult.success) {
67    // Queue everything else — user doesn't need to wait
68    await messageQueue.publish('order.confirmed', {
69      orderId: order.id,
70      items: order.items,
71    });
72    // Total user-facing latency: ~250ms (4x faster!)
73    return { status: 'confirmed', orderId: order.id };
74  }
75  return { status: 'payment_failed' };
76}
77
78// Background workers process the queued events:
79// Worker 1: updateInventory
80// Worker 2: sendConfirmationEmail
81// Worker 3: notifyWarehouse
82// Worker 4: updateAnalytics
83
84// Trade-off: Async is faster for users but adds complexity
85// (message queue, worker management, retry logic, eventual consistency)
86
87// ---------- Trade-off 3: Strong vs Eventual Consistency ----------
88
89// Strong consistency — for banking
90async function transferMoney(fromAccount, toAccount, amount) {
91  const transaction = await db.beginTransaction();
92  try {
93    // Both operations in ONE transaction — either both succeed or both fail
94    await transaction.query(
95      'UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?',
96      [amount, fromAccount, amount]
97    );
98    await transaction.query(
99      'UPDATE accounts SET balance = balance + ? WHERE id = ?',
100      [amount, toAccount]
101    );
102    await transaction.commit();
103    // Guarantee: balances are ALWAYS consistent
104    return { success: true };
105  } catch (e) {
106    await transaction.rollback();
107    return { success: false, error: e.message };
108  }
109}
110
111// Eventual consistency — for social media like counts
112async function likePost(userId, postId) {
113  // Write to fast local store immediately
114  await redis.sadd(`post:\${postId}:likes`, userId);
115
116  // Asynchronously update the main database
117  // The count might be slightly off for a few seconds — that's OK!
118  await messageQueue.publish('post.liked', { userId, postId });
119
120  // Return immediately — user sees their like instantly
121  return { liked: true };
122}
123
124// Trade-off: Bank transfers MUST be strongly consistent (can't lose money)
125// Social media likes can be eventually consistent (it's fine if the count
126// shows 41 instead of 42 for a few seconds)