System Design Roadmap - System Design & AI Learning Platform https://systemdrd.com Comprehensive feed for System Design courses, AI Agents tutorials, Hands-On lessons, ebooks, newsletters, and educational content. Learn distributed systems, microservices, and AI development. Mon, 29 Jun 2026 03:47:32 +0000 en-US hourly 1 https://wordpress.org/?v=7.0 https://systemdrd.com/wp-content/uploads/2025/10/cropped-ChatGPT-Image-Sep-4-2025-at-09_23_55-PM-32x32.png System Design Roadmap https://systemdrd.com 32 32 - Digital Book #respond

Digital Book

100 questions, 40 checklist items. Now rebuild:

Ran 2 commands, read a file

Ran 2 commands, read a file

The Interview Prep Bundle PDF is complete. Here’s exactly what’s in it:

51 pages · 126 KB

SectionQuestionsTopics
§1 Producers25acks, idempotence, transactions, batching, compression, partitioning
§2 Consumers25offset commits, rebalancing, heartbeats, EOS, KIP-848 new protocol
§3 Kafka Streams20KStream/KTable, windowing, Processor API, state stores, interactive queries
§4 Kafka Connect12CDC/Debezium, SMTs, converters, DLQ, exactly-once source
§5 Operations11ISR, retention, compaction, KRaft, partition reassignment
§6 Security7TLS, SASL mechanisms, ACLs, mTLS, cert rotation
system design Checklist—40 checkpoints across 8 categories
Config Reference—48 entries across Producer / Consumer / Broker / Streams

Every answer is sourced directly from the StreamSocial and Uber-Lite curriculum content — nothing generic, nothing fabricated. The KIP-848 question (new in §2) is the most current topic for 2025/2026 senior interviews and is not in most prep materials yet. That’s the edge this bundle has. Price it at $79 on Gumroad and it’s ready to upload.

]]> - Hands-On Lesson #respond

Hands-On Lesson

## Lesson 10 : Advanced Dashboard Platform

## What We Are Building

InfraWatch **Dashboard** — a Grafana-class observability console for infrastructure operators:

1. **Composable Grid** — Drag-and-drop widgets with persistent layouts and a widget library
2. **Advanced Charts** — Multi-series, stacked, scatter, heatmap, latency distribution, status timelines
3. **Customization** — Per-dashboard themes, save/load layouts, tokenized sharing
4. **Interactive Analytics** — Cross-filtering, drill-down hierarchy, time-range presets
5. **performance Layer** — LTTB downsampling, Redis query cache, WebSocket live streams
6. **Template Gallery** — Semver-versioned marketplace with ratings and one-click deployment

—

## Core Concept

Datadog and Grafana do not render raw million-point time series to the browser. They **downsample at query time** (LTTB algorithm), **cache aggregated buckets in Redis**, and **push deltas over WebSockets** so the UI stays at 60fps. The insight most tutorials miss: the dashboard is a *composition engine* — widgets are independent data contracts, not hard-coded charts. Layout state (x, y, w, h) persists separately from widget config, enabling template reuse without duplicating query logic.

—

## Where This Fits

“`
InfraWatch Reports (exports + analytics API)
│
InfraWatch Dashboard ◀ this module
│
Operator fleet monitoring
“`

Dashboard consumes aggregated metric samples upstream and presents the operator’s primary control surface for fleet health.

—

## Component Architecture

“`
React Console (:5230)
│ REST + WebSocket
FastAPI Gateway (:5060)
│
┌────┴────┬──────────┐
PostgreSQL Redis LTTB Engine
:5490 :6440
“`

| Service | Port | Image | Role |
|———|——|——-|——|
| backend | 5060 | python:3.12-slim | FastAPI + WebSocket metrics |
| frontend | 5230 | node:22 / nginx | Grafana-style console |
| postgres | 5490 | postgres:16-alpine | Dashboards, widgets, metrics |
| redis | 6440 | redis:7-alpine | Chart query cache |

### Project Layout

Once you open the project folder, here is how the code is organized. Think of it as three layers: the API (backend), the browser UI (frontend), and the scripts that wire everything together.

“`
infrawatch-dashboard/
├── backend/
│ ├── app/
│ │ ├── main.py # FastAPI app, lifespan, CORS
│ │ ├── API/
│ │ │ ├── dashboards.py # Dashboard CRUD, layout, widgets
│ │ │ ├── charts.py # Multi-series, stacked, scatter, heatmap
│ │ │ ├── filters.py # Cross-filter options
│ │ │ ├── drilldown.py # Hierarchy navigation
│ │ │ ├── templates.py # Marketplace CRUD, instantiate
│ │ │ ├── sharing.py # Share tokens
│ │ │ ├── performance.py # Cache stats, WebSocket, Prometheus
│ │ │ └── operations.py # Overview, demo, E2E
│ │ ├── core/ # config, database
│ │ ├── models/ # Dashboard, Widget, Template, MetricSample
│ │ ├── schemas/ # Pydantic request/response
│ │ └── services/
│ │ ├── metrics_service.py # Query, aggregate, LTTB pipeline
│ │ ├── cache_service.py # Redis query cache
│ │ ├── downsample.py # LTTB algorithm
│ │ ├── template_service.py # Semver, instantiate
│ │ └── seed.py # 1900+ metric samples
│ ├── tests/
│ │ ├── conftest.py
│ │ └── test_api.py
│ ├── Dockerfile
│ └── requirements.txt
├── frontend/
│ ├── src/
│ │ ├── pages/ # Console, Marketplace, performance
│ │ ├── components/
│ │ │ ├── dashboard/ # Grid, WidgetRenderer, FilterPanel
│ │ │ └── Layout.tsx
│ │ ├── API/client.ts
│ │ ├── store/filterStore.ts # Zustand state
│ │ └── hooks/useMetricsStream.ts
│ ├── package.json
│ └── Dockerfile
├── docker-compose.yml
├── requirements.txt
├── requirements-dev.txt
├── build.sh
├── stop.sh
└── cleanup.sh
“`

### How the Pieces Work Together

**Widget Grid.** Dashboards store layout as JSON (`x`, `y`, `w`, `h` per widget). `react-grid-layout` handles drag-and-resize on the frontend. Layout saves via `PUT /API/v1/dashboards/{id}/layout` with optimistic versioning — the server returns HTTP 409 on version conflict.

**Chart Pipeline.** `MetricsService.timeseries()` buckets raw `MetricSample` rows into 5-minute windows, then applies LTTB downsampling when points exceed 1920. Results cache in Redis (60s TTL) before JSON serialization.

**Cross-Filter and Drill-Down.** Zustand store holds `timeRange`, `services[]`, `regions[]`, and `drillPath[]`. Progressive filter options come from `/API/v1/filters/available`. Drill-down navigates service → endpoint → region → environment via `/API/v1/drilldown/navigate`.

**Template Marketplace.** Templates store `config: { layout, widgets, theme }`. Instantiating creates a new Dashboard and Widget rows. Config changes bump semver (major if widget removed, minor if added, patch otherwise).

**Real-Time Stream.** WebSocket at `/API/v1/performance/stream` pushes `metrics_batch` every 3 seconds. The frontend `useMetricsStream` hook updates the live point counter in the performance panel.

—

## Control & Data Flow

1. Operator selects time range and cross-filters (service, region)
2. API checks Redis; cache misses query indexed `metric_samples` rows
3. LTTB reduces points to ≤1920 before JSON serialization
4. WebSocket pushes metric batches every 3s for live widgets
5. Drag-resize triggers versioned layout save (optimistic locking on conflict)

—

## Widget Lifecycle

—

## Operator Console

The UI follows a Grafana-inspired dark theme (`#111217` background, `#73BF69` accent). Four alternate themes ship with the project: light, ocean, and sunset.

| Page | Route | What You See |
|——|——-|————–|
| Command Center | `/` | KPI cards, widget grid, filters, drill-down, performance panel |
| Template Gallery | `/marketplace` | Search, ratings, one-click deploy |
| performance | `/performance` | Cache stats, WebSocket status, live points |

### Widget Types

| Type | What It Shows |
|——|—————|
| `metric_card` | Single KPI value |
| `multi_series` | Line chart, multiple metrics |
| `stacked` | Stacked bar by service |
| `scatter` | CPU vs memory |
| `heatmap` | Traffic by hour/day |
| `status_timeline` | Service status chips |
| `latency` | Latency distribution histogram |

—

## API Reference

These are the endpoints you will call from the frontend or test with curl.

### Dashboards

| Endpoint | Method | Purpose |
|———-|——–|———|
| `/API/v1/dashboards` | GET | List dashboards |
| `/API/v1/dashboards` | POST | Create dashboard |
| `/API/v1/dashboards/{id}` | GET | Dashboard detail + widgets |
| `/API/v1/dashboards/{id}/layout` | PUT | Persist grid layout |
| `/API/v1/dashboards/{id}/theme` | PUT | Change theme |
| `/API/v1/dashboards/{id}/widgets` | POST | Add widget |

### Charts

| Endpoint | Purpose |
|———-|———|
| `GET /API/v1/charts/timeseries` | LTTB-downsampled time series |
| `GET /API/v1/charts/multi-series` | Multi-metric lines |
| `GET /API/v1/charts/stacked` | Stacked bar by service |
| `GET /API/v1/charts/scatter` | CPU vs memory correlation |
| `GET /API/v1/charts/heatmap` | Hour/day traffic heatmap |
| `GET /API/v1/charts/latency-distribution` | Latency histogram |
| `GET /API/v1/charts/status-timeline` | Service status events |

### Filters, Drill-Down, Templates, and Sharing

| Endpoint | Method | Purpose |
|———-|——–|———|
| `/API/v1/filters/available` | GET | Cross-filter options with counts |
| `/API/v1/drilldown/navigate` | POST | Drill into hierarchy level |
| `/API/v1/drilldown/details` | POST | Detail records for path |
| `/API/v1/templates` | GET | Marketplace search |
| `/API/v1/templates/{id}/instantiate` | POST | Deploy template as dashboard |
| `/API/v1/templates/{id}/rate` | POST | Rate template |
| `/API/v1/sharing/{id}/share` | POST | Create share link |
| `/API/v1/sharing/shared/{token}` | GET | View shared dashboard |

### performance and Operations

| Endpoint | Purpose |
|———-|———|
| `GET /API/v1/performance/cache` | Cache hit rate stats |
| `GET /API/v1/performance/stats` | Uptime, clients, cache |
| `GET /API/v1/performance/prometheus` | Prometheus metrics |
| `WS /API/v1/performance/stream` | Live metric batches |
| `GET /API/v1/operations/overview` | Dashboard KPIs |
| `POST /API/v1/operations/demo` | Inject live metric samples |
| `POST /API/v1/operations/e2e` | Pipeline validation |

Quick health check after the stack is running:

“`bash
curl -s http://localhost:5060/API/health
curl -s http://localhost:5060/API/v1/operations/overview | python3 -m json.tool
“`

—

## Build, Test, and Demo

Everything runs from inside the `infrawatch-dashboard` folder. Make the scripts executable once, then pick the mode that fits your machine.

“`bash
cd infrawatch-dashboard
chmod +x build.sh stop.sh cleanup.sh
“`

### Step 1 — Run Tests First

Always start here. If tests pass, your environment is wired correctly before you spin up services.

“`bash
./build.sh test # 14 pytest + 1 vitest
“`

| Suite | Count | What It Covers |
|——-|——-|—————-|
| pytest | 14 | health, overview, charts, filters, drilldown, templates, layout, sharing, cache, e2e |
| vitest | 1 | App renders InfraWatch Dashboard branding |

Backend tests use in-memory SQLite with `StaticPool` and dependency overrides in `tests/conftest.py`.

### Step 2 — Start the Stack (Hybrid Mode)

This is the recommended path for daily development. Postgres and Redis run in Docker; the API and UI run on your host machine.

### Without Docker (local dev)

“`bash
cd infrawatch-dashboard
./build.sh local # Postgres/Redis in Docker, API+UI on host
./build.sh demo # inject metrics, verify non-zero chart points
“`

Open **http://localhost:5230** — Command Center shows live KPI cards and charts.

Expected output from `./build.sh demo`:

“`
{“status”:”healthy”,”service”:”infrawatch-dashboard”}
Metric samples: 1900+ | Chart points: 9+
{“passed”: true}
Open http://localhost:5230
“`

### Step 3 — Full Docker Stack (Optional)

Use this when you want every service inside containers, matching a production-like layout.

### With Docker (full stack)

“`bash
./build.sh docker
./build.sh demo
“`

Requires Docker Hub access for `python:3.12-slim`, `node:22-alpine`, `nginx:alpine`, `postgres:16-alpine`, and `redis:7-alpine`. If your network blocks Docker Hub, pre-pull the images:

“`bash
docker pull python:3.12-slim node:22-alpine nginx:alpine postgres:16-alpine redis:7-alpine
./build.sh docker
“`

Or run compose directly:

“`bash
docker compose up –build -d
docker compose logs -f backend
docker compose down -v
“`

### Step 4 — Verify the Dashboard

Walk through these checks in the browser after `./build.sh demo`:

1. Command Center KPI cards show non-zero numbers (not dashes or zeros)
2. Charts render with visible data points
3. Drag a widget, refresh the page — layout stays where you left it
4. performance page shows WebSocket as Connected with live points updating
5. Template Gallery lists templates and Deploy Template creates a new board

**Success criteria:** `metric_samples > 0`, chart `points > 0`, E2E checks all pass, dashboard KPIs update after demo injection.

### Stop and Clean Up

When you are done for the day:

“`bash
./stop.sh # stop host processes and Docker containers
./cleanup.sh # remove node_modules, venv, caches, prune Docker resources
“`

—

## Key Source Files

If you get lost in the codebase, start with these files.

| Path | Role |
|——|——|
| `backend/app/main.py` | FastAPI app, lifespan, router registration |
| `backend/app/services/metrics_service.py` | Query, aggregate, chart data |
| `backend/app/services/downsample.py` | LTTB downsampling |
| `backend/app/services/cache_service.py` | Redis query cache |
| `backend/app/services/seed.py` | Metric samples + default dashboard |
| `backend/app/API/performance.py` | WebSocket stream, Prometheus |
| `frontend/src/pages/Console.tsx` | Main dashboard with grid + filters |
| `frontend/src/components/dashboard/WidgetRenderer.tsx` | Chart widgets |
| `frontend/src/components/dashboard/DashboardGrid.tsx` | react-grid-layout |
| `frontend/src/API/client.ts` | Typed API client |
| `frontend/src/hooks/useMetricsStream.ts` | WebSocket live updates |

—

## Troubleshooting

| Issue | Fix |
|——-|—–|
| Port 5060/5230 in use | `./stop.sh` then retry |
| Dashboard zeros | Run `./build.sh demo` or click refresh icon in UI |
| Layout 409 conflict | Refresh page to get latest version |
| Docker build fails | Use `./build.sh local` (hybrid mode) |
| Stale node_modules | `./cleanup.sh` then `./build.sh local` |
| Redis cache always miss | Ensure Redis container on :6440 |

—

## Assignment

Build a **custom widget type** `alert_summary` that displays the top 5 services by error-rate from the aggregated API. Add it to the widget library, persist it on a dashboard, and verify layout survives page refresh.

### Solution Hints

1. Extend `WidgetRenderer` with a new case calling `/API/v1/charts/aggregated?group_by=service`
2. Register the type in `WidgetLibrary` with an appropriate icon
3. POST to `/API/v1/dashboards/{id}/widgets` with `widget_type: alert_summary`
4. Confirm layout JSON in GET `/API/v1/dashboards/{id}` includes your widget’s grid position

—

*Next: User & Team Management — multi-tenant dashboards with RBAC inheritance.*

]]> - Hands-On Lesson #respond

Hands-On Lesson

## Lesson 9: Data Export & Reporting Platform
## What We Are Building

InfraWatch **Reports** — a production-grade export and reporting control plane:

1. **Export Engine** — Multi-format streaming exports (CSV, JSON, Excel, PDF) with checksum validation
2. **Report Templates** — Jinja2-driven dynamic reports with preview and scheduled delivery
3. **Visualization API** — Chart endpoints with pre-aggregated hourly metrics and Redis caching
4. **Advanced Analytics** — Statistical baselines, anomaly detection, forecasting, and correlation matrices
5. **performance Layer** — Query caching, index recommendations, Prometheus metrics, slow-query tracking
6. **Operator Console** — Grafana-inspired dashboard with export wizard, real-time progress, and history

—

## Core Concept

Export systems in production (Datadog, Grafana, Splunk) never dump raw tables to users. They **stream, compress, and cache** query results because a single unbounded export can saturate database I/O and starve live dashboards. The non-obvious insight: treat exports as **asynchronous jobs with TTL-bound artifacts**, not synchronous API responses. Grafana’s report renderer and Datadog’s scheduled snapshots both follow this pattern — queue the work, stream batches, validate integrity, expire the file.

—

## Where This Fits

“`
InfraWatch Realtime (live streams)
│
InfraWatch Reports ◀ this module
│
InfraWatch Dashboard (widgets)
“`

Reports consumes aggregated metrics and notification data upstream, producing downloadable artifacts and scheduled executive summaries downstream.

—

## Component Architecture

| Service | Port | Image | Role |
|———|——|——-|——|
| backend | 5050 | Dockerfile | FastAPI API + WebSocket progress |
| frontend | 5220 | Dockerfile / Vite | Operator console |
| postgres | 5480 | postgres:16-alpine | Metrics, jobs, templates |
| redis | 6430 | redis:7-alpine | Chart query cache |

The API sits in the middle. The React console talks to it over REST and WebSocket. PostgreSQL stores your metrics and export jobs. Redis caches chart queries so repeated dashboard loads do not hammer the database.

—

## Inside the Project

Once you open the repository, the layout maps directly to those services:

“`
infrawatch-reports/
├── backend/
│ ├── app/
│ │ ├── main.py # FastAPI app, lifespan, WebSocket
│ │ ├── API/ # exports, templates, schedules, analytics
│ │ ├── core/ # config, database
│ │ ├── models/ # ExportJob, MetricSample, etc.
│ │ ├── schemas/ # Pydantic request/response
│ │ └── services/ # export_engine, analytics, cache, seed
│ ├── tests/test_api.py
│ └── requirements.txt
├── frontend/
│ ├── src/pages/ # 7 console pages
│ ├── src/API/client.ts
│ └── package.json
├── docker-compose.yml
├── build.sh
├── stop.sh
└── cleanup.sh
“`

You do not need to memorize every file. Focus on three folders: `API/` (routes), `services/` (business logic), and `frontend/src/pages/` (what the operator sees).

—

## How the Pieces Work Together

**Export engine.** A POST to `/API/v1/exports` creates a job. The job moves through `pending`, `processing`, and `completed` (or `failed` / `expired`). Rows stream in batches, the file gets an MD5 checksum, and downloads expire after 24 hours.

**Report templates.** Jinja2 templates support variable extraction, live preview, and scheduled generation. A weekly summary template is seeded on first startup.

**Analytics pipeline.** Raw metric samples roll up into hourly buckets. Chart endpoints check Redis first (60-second TTL), then PostgreSQL. Anomaly detection uses z-scores; forecasting uses linear regression; correlations use Pearson coefficients.

**performance layer.** In-memory cache plus Redis, latency histograms at P50/P95/P99, connection pool stats, and a Prometheus endpoint at `/API/v1/performance/prometheus`.

—

## Control & Data Flow

1. Operator selects data source and format in the export wizard
2. API checks Redis cache for chart queries; misses hit PostgreSQL with indexed scans
3. Export engine streams rows in batches, writes file, computes MD5 checksum
4. WebSocket pushes progress stages: fetching → converting → complete
5. Completed files expire after 24 hours; Prometheus records latency percentiles

—

## Export Job Lifecycle

Every export job follows this path. If something breaks during processing, the job lands in `failed` with an error message. If nobody downloads within 24 hours, it moves to `expired`.

—

## API Reference

### Exports

| Endpoint | Method | Purpose |
|———-|——–|———|
| `/API/v1/exports` | POST | Create export job |
| `/API/v1/exports` | GET | List jobs |
| `/API/v1/exports/{id}` | GET | Job status |
| `/API/v1/exports/{id}/download` | GET | Download file |
| `/API/v1/exports/{id}` | DELETE | Cancel job |

### Templates and Schedules

| Endpoint | Method | Purpose |
|———-|——–|———|
| `/API/v1/templates` | GET/POST | Template CRUD |
| `/API/v1/templates/{id}/preview` | POST | Render preview |
| `/API/v1/schedules` | GET/POST | Cron schedules |
| `/API/v1/schedules/run-due` | POST | Trigger due schedules |

### Analytics

| Endpoint | Purpose |
|———-|———|
| `GET /API/v1/analytics/chart` | Multi-series chart data |
| `GET /API/v1/analytics/trends` | Direction, percent change, moving average |
| `GET /API/v1/analytics/compare` | Dimension comparison |
| `GET /API/v1/analytics/drilldown` | Channel to template hierarchy |
| `GET /API/v1/analytics/statistics/{metric}` | mean, p95, p99 |
| `GET /API/v1/analytics/anomalies` | z-score detection |
| `GET /API/v1/analytics/predictions/{metric}` | Forecast with confidence band |
| `GET /API/v1/analytics/correlations/{metric}` | Cross-metric Pearson r |

### Operations

| Endpoint | Purpose |
|———-|———|
| `GET /API/v1/operations/overview` | Dashboard KPIs |
| `POST /API/v1/operations/demo` | Sample export |
| `POST /API/v1/operations/e2e` | Pipeline validation |

Quick API check after the stack is running:

“`bash
curl -s http://localhost:5050/API/health
curl -s http://localhost:5050/API/v1/operations/overview | python3 -m json.tool
“`

—

## Operator Console

The UI uses a Grafana-inspired dark theme. Each sidebar page maps to one part of the platform:

| Page | Route | What you will see |
|——|——-|——————-|
| Overview | `/` | 8 KPI cards and a delivery volume chart |
| Exports | `/exports` | 3-step wizard and job table |
| Templates | `/templates` | Jinja2 template cards |
| Schedules | `/schedules` | Cron schedule table |
| Analytics | `/analytics` | Comparison, trends, stats, anomalies, predictions, correlations |
| performance | `/performance` | Latency percentiles, CPU, cache stats |
| History | `/history` | Completed and failed export log |

Walk every page after startup. If KPIs show zero, run the demo step below before assuming something is broken.

—

## Build, Test and Demo

### Prerequisites

Python 3.12+, Node.js 22+, and Docker with Compose v2. Ports 5050, 5220, 5480, and 6430 must be free.

### Step 1 — Enter the project and make scripts executable

“`bash
cd week9/infrawatch-reports
chmod +x build.sh stop.sh cleanup.sh
“`

### Step 2 — Run tests

“`bash
./build.sh test
“`

This runs 14 pytest cases (health, charts, exports, download, end-to-end) and 1 vitest case (UI renders). All should pass before you start the stack.

### Step 3 — Start the stack (hybrid mode, recommended)

Postgres and Redis run in Docker; API and UI run on the host.

“`bash
./build.sh local
“`

Open **http://localhost:5220**. The API listens on **http://localhost:5050**.

### Step 4 — Run the demo validation

With the stack running:

“`bash
./build.sh demo
“`

**Expected demo output:**

“`
{“status”:”healthy”,”service”:”infrawatch-reports”}
Metric samples: 2500+ | Delivery volume: >0
{“passed”: true, “chart_points”: >0, “export_rows”: >0}
Open http://localhost:5220
“`

### Step 5 — Walk the UI manually

1. **Overview** — confirm KPI cards are not zero; click **Generate Sample Export**
2. **Exports** — click Next twice, then **Start Export**; wait for the spinner; download the file
3. **Analytics** — open each tab; charts should render with real data
4. **performance** — CPU and latency values should update

### Full pipeline in one command

“`bash
./build.sh all
“`

Runs test, local start, and demo in sequence.

### With Docker (full stack)

“`bash
./build.sh docker
“`

Requires Docker Hub access for `python:3.12-slim`, `node:22-alpine`, and `nginx:alpine`. If Hub is unreachable, the script falls back to hybrid mode automatically.

Pre-pull images when your network is stable:

“`bash
docker pull python:3.12-slim node:22-alpine nginx:alpine postgres:16-alpine redis:7-alpine
./build.sh docker
“`

On WSL, if you see `lookup registry-1.docker.io: no such host`:

“`bash
echo “nameserver 8.8.8.8” | sudo tee /etc/resolv.conf
“`

Restart Docker Desktop, then retry.

### Stop and clean up

“`bash
./stop.sh # stop host processes and compose stack
./cleanup.sh # remove node_modules, venv, caches, project Docker images
“`

—

## Success Criteria

– [ ] `./build.sh test` — all backend and frontend tests pass
– [ ] Overview KPIs show non-zero metric samples and delivery volume
– [ ] Export wizard creates downloadable CSV/JSON/Excel/PDF files
– [ ] Analytics tabs render comparison charts, trends, and correlations
– [ ] performance page shows live CPU and query latency percentiles
– [ ] Templates and schedules pages display seeded data

—

## Troubleshooting

| Issue | What to do |
|——-|————|
| Port 5050 in use | Run `./stop.sh`, then retry |
| Export button seems dead | Complete all 3 wizard steps; wait for the exporting spinner |
| Download shows server error | Restart backend; confirm export status is `completed` |
| Docker build fails on Hub | Use `./build.sh local` instead |
| Dashboard shows all zeros | Run `./build.sh demo` or **Generate Sample Export** |
| Stale dependencies | Run `./cleanup.sh`, then `./build.sh local` |

—

## Key Files to Know

| Path | Role |
|——|——|
| `backend/app/main.py` | FastAPI app, lifespan, WebSocket |
| `backend/app/services/export_engine.py` | Format writers, job processing |
| `backend/app/services/analytics_service.py` | Charts, trends, statistical analysis |
| `backend/app/services/cache_service.py` | Redis and memory cache |
| `backend/app/services/seed.py` | Sample metric data on startup |
| `frontend/src/pages/Exports.tsx` | Export wizard and download |
| `frontend/src/pages/Analytics.tsx` | Six-tab analytics console |
| `frontend/src/API/client.ts` | API client and export polling |

—

## Assignment

Add a custom report template that includes a bar chart of failure rates per channel. Schedule it to run every Monday at 08:00 UTC and deliver via email recipients list.

**Hints:** Create a Jinja2 template with a `{% for %}` loop over channel data. Use the `/API/v1/analytics/compare` endpoint variables in the template context. Register a cron schedule via the Schedules API with expression `0 8 * * 1`.

—

## Solution Hints

1. Fetch comparison data: `GET /API/v1/analytics/compare?metric_name=failure_rate`
2. POST to `/API/v1/templates` with HTML containing `{% for item in channels %}`
3. POST to `/API/v1/schedules` with `cron_expression: “0 8 * * 1″` and `email_recipients: [“you@domain.com”]`
4. Trigger manually: `POST /API/v1/schedules/run-due` after setting `next_run_at` to past

—

*Next: Advanced Dashboard Features — drag-and-drop widgets consuming these chart APIs.*

]]> - Page Update #respond

Page Update

]]> - Digital Book #respond

Digital Book

About Distributed Systems with .NET

This PDF is the lead magnet for Distributed Systems with .NET — a 45-post Substack series building one complete distributed log monitoring system in C# on Windows, using .NET Aspire, Azure Service Bus, Azure Event Hubs, Application Insights, Azure Data Explorer, DAPR, and Bicep.

Every Azure service runs on an official free Microsoft local emulator. No Azure subscription is required for any of the 45 posts.

]]> - System Design Course #respond

System Design Course

]]> - Page Update #respond

Page Update

]]> - System Design Course #respond

System Design Course

]]> - Newsletter Issue #respond

Newsletter Issue

system design Interview Roadmap – Step by step process that will make you comfortable, familiar and then expert at system design.

https://systemdr.substack.com/

https://sdcourse.substack.com

https://aieworks.substack.com/

https://aiamastery.substack.com/

]]>