FSD Frontend System Design

Part III — The Speed · Lesson 7.1

Logging & Monitoring Overview

In one lineLogs, metrics, and traces answer three different questions — you need all three to debug production.

Where you've seen itCheckout starts failing at 2am. The graph would have shown it instantly; instead the sales team reports it at 9am.

  • Time13 min
  • DiagramThree pillars and the questions each one answers
  • Chapter7 · Logging & Monitoring

Diagram

diagram
THE THREE PILLARS

  ┌──────────────┬──────────────────────┬────────────────────────┐
  │   METRICS    │        LOGS          │        TRACES          │
  ├──────────────┼──────────────────────┼────────────────────────┤
  │ numbers over │ discrete events with │ one request's path     │
  │ time         │ context              │ across services        │
  │              │                      │                        │
  │ "error rate  │ "TypeError: cannot   │ "this checkout spent   │
  │  is 4.2%"    │  read 'id' of undef, │  1.8s in pricing,      │
  │              │  user 91, /checkout" │  40ms in inventory"    │
  ├──────────────┼──────────────────────┼────────────────────────┤
  │ IS something │ WHAT exactly         │ WHERE in the system    │
  │ wrong?       │ happened?            │ did it go wrong?       │
  ├──────────────┼──────────────────────┼────────────────────────┤
  │ cheap, fast, │ expensive at volume, │ moderate, needs        │
  │ aggregate    │ precise              │ propagated ids         │
  └──────────────┴──────────────────────┴────────────────────────┘
diagram
THE LOOP — this chapter in one picture

  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
  │ COLLECT  │──►│  ALERT   │──►│  TRIAGE  │──►│   FIX    │
  │  (7.2)   │   │  (7.3)   │   │  (7.4)   │   │  (7.4)   │
  └──────────┘   └──────────┘   └──────────┘   └────┬─────┘
       ▲                                            │
       └──────── add the signal you wished ─────────┘
                 you'd had during triage
diagram
FRONTEND-SPECIFIC SIGNALS — what the backend can't see

  JS errors + stack traces        (needs source maps — 7.4)
  unhandled promise rejections    the most-missed one
  failed fetches by endpoint      including CORS and network drops
  Core Web Vitals from real users (5.3)
  rage clicks / dead clicks       UX breakage with no exception
  console errors from 3rd parties your CSP violations too (3.4)

How it works

  1. Metrics for detection. Cheap to store, fast to query, and what alerts fire on.
  2. Logs for explanation. Sampled and structured, they tell you what happened in a specific failing session.
  3. Traces for location. A propagated request id ties a browser action to the backend spans it caused.
  4. Correlate with releases. Every signal should carry a build id, or "what changed?" is unanswerable.
  5. Close the loop. After each incident, add the one signal that would have made triage faster.

Trade-offs

SignalVolumeCostUse for
MetricslowlowAlerting, dashboards, trends
LogshighhighRoot cause on a specific case
TracesmediummediumCross-service latency
Session replayvery highvery highHard-to-reproduce UX bugs

Interview angle

"How do you know your frontend is healthy in production?"

  • Metrics first: JS error rate, failed request rate, and p75 Web Vitals, all sliced by release.
  • Alert on user-visible symptoms rather than causes — checkout success rate beats CPU usage.
  • Then logs and traces for depth, with a request id that connects a browser session to backend spans.

Recap

  • Metrics say is something wrong; logs say what; traces say where.
  • Tag everything with a release id — the first triage question is always "what shipped?"
  • Every incident should end by adding the signal you wished you'd had.