Fast-learner loop (use for every module): 1) Look at the diagram first — get the shape. 2) Read once, fast. 3) Say it out loud in 30 seconds. 4) Take the quiz. Anything you miss, re-read only that part.
APIs in 90 seconds
REST essentials
Resources, HTTP verbs (GET/POST/PUT/PATCH/DELETE), status codes (200, 201, 400, 401, 403, 404, 409, 429, 500), JSON bodies, pagination, filtering.
Idempotency
Retrying a POST safely. Use idempotency keys so a retry doesn't create duplicates — critical for payments and webhooks.
Status codes drill
| Code | Meaning | Your move |
|---|---|---|
| 401 | Unauthenticated | Check API key / token expiry / header name |
| 403 | Authenticated but not allowed | Check scopes / permissions |
| 429 | Rate limited | Backoff with jitter, queue, respect Retry-After |
| 500 / 502 / 503 | Server side | Retry with backoff; check status page; log request id |
Authentication — compare clearly
| Method | How it works | Use when |
|---|---|---|
| API key | Secret header, server-to-server | Simple integrations; rotate & store in env/secrets |
| Bearer / JWT | Signed token with expiry & claims | User sessions, service auth |
| OAuth 2.0 | User grants scoped access; access + refresh tokens | Google/Slack/HubSpot-style third-party access |
| Webhook signature | HMAC of payload with shared secret | Verify webhook really came from the provider |
Webhooks — the flow they'll ask you to draw
Provider event (payment.succeeded)
→ POST https://your-app/webhooks/stripe (with signature)
→ Verify signature + parse JSON
→ Return 200 FAST (don't do slow work inline)
→ Enqueue job → worker processes → update DB
→ Deduplicate by event id (providers retry!)Classic traps: Doing slow work before returning 200 (provider times out & retries), not verifying signatures, not deduplicating, no retry/dead-letter handling.
Databases & data flows
SQL vs NoSQL
SQL for structured, relational, transactional data. NoSQL for flexible documents / high-write event data. Know indexes, primary keys, joins at a basic level.
Data flow answer frame
Source → Ingest (API/webhook/file) → Validate → Transform/Classify → Store → Serve/Report → Monitor.
Queues
Decouple producers from slow consumers; absorb spikes; retry failed jobs; dead-letter queue for poison messages.
System design: design an AI ticket-classification system
- Clarify: volume, latency, categories, human review needed?
- Flow: Ticket arrives via webhook/API → queue → LLM classify (JSON schema) → confidence check → low-confidence to human queue → store in DB → dashboard/report.
- Reliability: idempotency, retries with backoff, DLQ, logging with correlation ids.
- Quality: golden-set evals, sample human review, track accuracy by category.
- Cost: small model first, escalate hard cases to a larger model.
Debugging playbook (use this structure live)
- Reproduce with the smallest failing input; note exact error, timestamp, request id
- Check: auth → payload shape → endpoint/version → rate limits → provider status
- Read logs in order; add structured logs if blind (input id, step, duration)
- Isolate: does it fail with curl/Postman outside your code? Then it's config/provider, not logic
- Fix, verify with the failing case + regression set, document root cause in the SOP
sequenceDiagram
participant P as Provider
participant A as Your API
participant Q as Queue
participant W as Worker
participant DB as Database
P->>A: POST /webhooks (event + signature)
A->>A: Verify HMAC signature
A->>A: Check event id seen before?
A-->>P: 200 OK (fast!)
A->>Q: Enqueue job
Q->>W: Process async
W->>DB: Update (idempotent)
W-->>Q: Ack / retry on failure
flowchart TD
E["Error occurs"] --> R{"Reproduced?"}
R -->|No| L["Add logs / find
smallest failing input"] L --> R R -->|Yes| I{"Fails in curl/Postman
outside your code?"} I -->|Yes| X["Provider / config / auth
rate limit / payload change"] I -->|No| Y["Your logic
fix + regression test"] X --> V["Verify + document
root cause in SOP"] Y --> V
smallest failing input"] L --> R R -->|Yes| I{"Fails in curl/Postman
outside your code?"} I -->|Yes| X["Provider / config / auth
rate limit / payload change"] I -->|No| Y["Your logic
fix + regression test"] X --> V["Verify + document
root cause in SOP"] Y --> V
flowchart LR
T["Ticket arrives
API / Webhook"] --> Q["Queue"] Q --> C["LLM classify
JSON schema"] C --> K{"Confidence
high?"} K -->|Yes| DB[(Database)] K -->|No| H["Human review queue"] H --> DB DB --> R["Dashboard /
daily report"] C -.->|log every run| M["Monitor: accuracy
cost / failures"]
API / Webhook"] --> Q["Queue"] Q --> C["LLM classify
JSON schema"] C --> K{"Confidence
high?"} K -->|Yes| DB[(Database)] K -->|No| H["Human review queue"] H --> DB DB --> R["Dashboard /
daily report"] C -.->|log every run| M["Monitor: accuracy
cost / failures"]
Test yourself
Module 2 Test — APIs, Webhooks, Auth & Systems
Tap an answer — explanation appears instantly. Pass mark: 70%. Retake until you pass.
You get HTTP 401. First check?
Why: 401 = unauthenticated. Check credentials before anything else.
You get HTTP 429. Correct response?
Why: Backoff with jitter protects you and the provider.
A webhook arrives 5 times for one payment. Why?
Why: Slow 200 → provider retries. Return fast, enqueue, dedupe.
OAuth 2.0 is best when…
Why: OAuth = delegated, scoped, refreshable access on behalf of a user.
Making a POST safely retryable is called…
Why: Idempotency means retries don't create duplicates.
Slow worker is overwhelmed by spikes. Best pattern?
Why: Queues absorb spikes, decouple speed, and DLQ isolates bad jobs.
0 / 6 correct