What is Sysiq and how is it different from reading static blogs?

Sysiq is an interactive system design platform where you don't just read about distributed systems — you actively build and test them. Solve real-world engineering challenges using a live diagram canvas, guided architectural labs, and real-time napkin math estimation tools.

Is Sysiq suitable for preparing for FAANG system design interviews?

Yes. Sysiq is tailored specifically for mid-level, senior, and staff engineering interviews (L4–L7). The problem bank covers actual interview scenarios: URL shorteners, distributed rate limiters, key-value stores, video streaming architectures, and real-time chat systems.

Can I use Sysiq for free?

Yes. Foundational modules, introductory interview problems, the Napkin Math calculator, and the global engineering leaderboard are all free with no time limit.

Do I need prior distributed systems experience to get started?

Not at all. The curriculum starts with fundamental building blocks — DNS, reverse proxies, database replication, and caching — and progressively walks you up to complex architectures like Raft consensus, vector clocks, and LSM-tree compaction.

All Modules/Resilience & Observability

Observability Basics: Metrics, Logs & Traces

The three pillars of observability — what to instrument, how to correlate, and why it matters

12 min read

Slow checkout is a symptom, and guessing is not a diagnosis

The breaker tripped at 50 percent errors over 10 seconds and served stale cache. Which half failed, and did the fallback actually serve? Users report slow checkout. Is it the database, the cache, or a struggling region? Without signals you guess, and every team guesses a different culprit. Think of a doctor visit as the single analogy here: temperature charts over time, lab notes per incident, and imaging that follows one patient through the building. Observability, which is the ability to ask arbitrary questions about the system without shipping new code, works the same way by correlating three signals: metrics, which are aggregated numbers over time, logs, which are discrete event records, and traces, which are per-request trees showing where time went.

The naive fix is adding a dashboard per service and calling it done. That fails because dashboards answer only the questions someone predicted: the novel failure needs the unpredicted question, such as which 2 percent of checkouts with which payment method slowed after which deploy. The real solution is correlated signals with shared identifiers, so one alert walks to one slow request in seconds.

Pillar	What	Cardinality	Use
Metrics	Counters, gauges, and histograms, which are counts, current values, and bucketed distributions, aggregated over time	Low per label, cheap to store for months	Alerts, service objectives, trends
Logs	Discrete events as structured lines, preferably JSON with named fields	High, one line per request or event	Ground truth for the exact failing case
Traces	Span tree per request, where each span is one timed step from gateway to service to database	High, controlled by sampling	Latency breakdown, critical path, dependency graph

One identifier ties the chart to the patient to the scan

Correlation is the trick, not collection

Propagate a trace id, which is a unique identifier for one request across services, plus a span id per step, through headers following the W3C traceparent standard, log both as fields on every line, and expose them as metric exemplars, which are sample trace links attached to chart buckets. Then one alert walks metric to exemplar to trace to log without guessing.

Structured logs as JSON with the trace id indexed let you pivot from a slowest-percentile spike to the exact failing requests in seconds, which unstructured text grep cannot do at scale.

Instrument the user-visible path first

RED, which is rate, errors, and duration per service and endpoint, for what users feel, plus USE, which is utilization, saturation, and errors inside each box, for why it feels that way.
Histogram buckets for latency rather than averages, because percentiles need distributions: export buckets such as 50ms through 2.5s with exemplars linking slow buckets to sample traces.
Adaptive sampling, which keeps all errors and slow requests but a fraction of successes: 100 percent of errors and slowest-tail requests, 1 percent of healthy traffic.

Two dashboards take slow checkout from ticket to root cause in ninety seconds

Slow checkout arrives as a ticket with no numbers. The engineer who opens a RED dashboard, which shows request rate, error ratio, and duration per endpoint, sees checkout errors jump from 0.1 percent to 8 percent at 14:02 while the slowest percentile triples, then drops to the USE view, which shows utilization and saturation per dependency, and finds the database disk at 100 percent saturation. Two dashboards, ninety seconds, root cause named. Without them the same ticket becomes a four-hour guessing war between teams, because each team brings its own chart with no shared identifier.

text

RED per service/endpoint (what users feel):
  Rate:    req/s per route (checkout POST: 400/s baseline)
  Errors:  5xx ratio (alert: > 1% for 5 min, page: > 5% for 2 min)
  Duration: p50/p95/p99 histogram (alert: p99 > 800ms for 10 min)

USE per box/dependency (why it feels that way):
  Utilization: CPU > 75% sustained, connection pool > 80%
  Saturation:  queue depth, disk wait, GC pause time
  GC, which is garbage collection, the runtime reclaiming memory in stop-the-world pauses
  Errors:      DB slow-query count, downstream timeout ratio

SLO shape: 99.9% of checkout < 500ms over 30d -> error budget 43 min/mo
  SLO, which is a service-level objective, the promised threshold the budget measures

Histograms expose the tail that averages hide

Average latency hides the 5 percent of users timing out behind a healthy mean. Export histogram buckets at 50ms, 100ms, 250ms, 500ms, 1s, and 2.5s so the slowest percentiles compute server-side, and attach exemplars linking slow buckets to sample trace ids for one-click diagnosis.

Log one JSON line per request, nothing more

One JSON line per request with timestamp, INFO level in production, trace id, user id, route template, status, and duration in milliseconds. DEBUG stays in development, because in production it costs terabytes and leaks personal data into a system everyone can read.

One careless label turns monitoring into the outage

Someone adds user id as a metric label on the request counter. With 2 million users times 50 routes, that is 100 million series, where a series is one unique label combination stored and indexed, and the metrics backend falls over with queries timing out exactly when the incident starts. High-cardinality identifiers, which are values with millions of distinct possibilities such as user ids and request ids, belong in traces and logs, never in metric labels. The edge case teams miss is the raw URL path: templated routes such as orders by id produce 50 series, while raw paths with one entry per order id produce millions.

text

label discipline:
  OK labels: service, route template (/orders/:id), status class (5xx), region
  NEVER labels: user_id, email, request_id, trace_id, raw URL path
  series estimate: routes(50) x status(5) x region(4) = 1,000 series (fine)
  with user_id(2M): 2M x 50 x 5 x 4 = 2B series (outage + invoice)

sampling that keeps the signal:
  traces: 100% of errors + >p95 slow, 1% of success (adaptive by rate)
  logs: INFO sampled 100% for errors, WARN+ always; DEBUG off in prod

Alert fatigue is an observability failure, not a team attitude problem. Every alert must name an owner and a runbook action, where a runbook is the written fix-it procedure for that alert: a bare CPU-high alert with no action is noise, while checkout slowest-percentile past objective with a rollback candidate is signal. Delete or retune any alert that fires without action twice.

Keep the cheap aggregates forever and sample the expensive detail

1Metrics serve alerts and objectives, logs serve per-event truth, and traces show where time went, correlated by trace id so one alert walks to one request in seconds.
2Cost trades against resolution: cheap aggregates stay for months, expensive traces sample adaptively at all errors plus the slow tail and 1 percent of healthy traffic, and high-cardinality ids never enter metric labels.
3Full tracing at 10,000 requests per second with 1-kilobyte spans costs about 864 gigabytes per day, which is why complete error and tail coverage plus thin success sampling stays solvent while full capture does not.

Metrics scream, logs confess, traces draw the map. With all three correlated, slow checkout stops being a mystery and becomes a row in a table with a name on it. One question remains, and no chart answers it: the budget says 43 minutes a month, and March spent 40 by week two. Do you freeze ships or spend the last 3 minutes on the risky migration?

Resilience Patterns: Circuit Breakers, Bulkheads & Load Shedding

Next: Lab

Try an interactive lab

See the concept running

Then: Quiz

Test retention

Quick recall