Tools

Failure Lab

Enable JavaScript to step through a simulated pipeline: Producer → Queue → Workers → Store. Pause workers, interrupt writes or inject a traffic burst, then restore service and inspect recovery.

The model admits 3 events per simulated second (12 during a burst), allows 5 processing attempts per tick and holds 24 queued messages. A message gets at most 3 total attempts before entering a dead-letter queue. Backoff waits 1 second, then 2 seconds; jitter is not modeled. Arrivals enter before processing; delayed retries also occupy queue slots.

This is a deterministic teaching model, not a benchmark or a real fault injector. Rejected events and dead letters are not automatically replayed.

Compare two retry policies against the same 30-second incident. The second adds seeded, reproducible jitter to backoff. Inspect completed, queued, rejected and dead-letter messages in the timeline; neither policy is assumed to win. The manual simulator above retains its no-jitter policy.

Plan inference memory

Enable JavaScript to adjust weights, GQA/MHA KV cache and planning reserve. Without the tool: weight bytes = total parameters × bits / 8. KV bytes = 2 × layers × KV heads × head dimension × tokens × concurrency × KV bytes per element. Divide by 2³⁰ for GiB. Count every resident expert in an MoE model.

This is a planning estimate, not a per-GPU sizing guarantee. Model layout, runtime buffers and placement still require measurement.

Choose a documented reference architecture or enter your own. Save a baseline A, change context, concurrency or precision, and compare scenario B by weights, cache and reserve. Lower memory is not a quality or speed score.

Explore data with SQL

Enable JavaScript to explore two tables with 16 fictional rows: inference scenarios and batch/streaming pipelines. Start with a guided question; the help explains each column with units and examples.

Combine AND/OR, IN, BETWEEN and LIKE filters; group and sort by several columns, remove duplicates with DISTINCT or limit results. Copy the query or download its CSV result. Only SELECT over one table at a time is allowed: no joins, subqueries or writes.

This is a local teaching interpreter, not DuckDB or a real data connection. No engine performance conclusions can be drawn from these datasets.

The query walkthrough explains actual row and group counts at each logical stage. It is not a database query planner or a runtime performance profile.

How much failure can this service tolerate?

Enable JavaScript to compare a service-level objective with observed errors or downtime. Request-based and time-based availability are separate modes; requests are not silently converted into minutes.

Error budget = eligible requests or window minutes × (1 − target). Burn rate = observed bad fraction ÷ (1 − target). With no observations, or a 100% target, the corresponding undefined ratios stay unavailable. Partial-window projections require explicit assumptions, not a promise about future traffic or availability.

What changes between these two data contracts?

Enable JavaScript to compare two flat table schemas locally. Start with the example, then review added or removed columns, type changes and nullability changes. Download the report for a migration review.

Each input is a JSON object with a columns array. Each column has a unique name, an allowed type and an explicit boolean nullable. This is a small table-schema format, not a full JSON Schema validator, SQL parser or schema-registry compatibility checker. No data is uploaded.

Risks depend on direction: old readers consuming new records and old records meeting new constraints are different checks. A rename appears as removal plus addition; nullability does not mean a field can be omitted.