Changelog

Newest first. One entry per phase or per feature update. Each entry says what changed for a reader, not how it was built.

B8: the book online

• The book is now published at book.theversehub.in on every change to main, built by its own GitHub Pages workflow and served on a custom domain. Reading it online keeps the map, the search box and the practice tools working, and the build now refuses to publish anything that looks like a secret.

B7: Serverless big picture

• Serverless: the big picture puts every serverless service on one map, built and designed, follows a booking through all of them, and gives a “which service for which job” table with the classic comparisons: SQS vs SNS vs EventBridge vs Step Functions, API Gateway vs AppSync vs ALB, and Lambda vs ECS. This completes the serverless batch of deep dives.

B7: SES deep dive

• SES explains identities, Easy DKIM, SPF and DMARC, the sandbox and production access, bounces, complaints, the suppression list and configuration sets. It shows why our sandbox sends unverified customers’ emails to the DLQ and what is missing before real customers.

B7: S3 deep dive

• S3 follows a ticket download and a poster upload through presigned URLs, consistency, storage classes and lifecycle, SSE-S3 versus SSE-KMS (with the KMS AccessDenied trap), Block Public Access, bucket versus IAM policies, CORS, Object Ownership, versioning and event notifications.

B7: EventBridge deep dive

• EventBridge explains buses, rules, event patterns, targets, archive and replay, the newer Custom Event Bus, and EventBridge Scheduler (at, rate, cron, time zones). It designs a day-before reminder that is idempotent by schedule name and processed-jobs key (explain-only).

B7: AppSync deep dive

• AppSync follows a GraphQL request through schema, JavaScript resolvers, data sources, pipeline resolvers, auth modes and caching. It designs live seat updates from our existing booking events, as refresh hints that never replace the booking transaction (explain-only).

B7: API Gateway deep dive

• API Gateway compares REST, HTTP and WebSocket APIs, their authorizers, caching, throttling and current integration limits. A proposed check-in endpoint keeps operator identity, ticket verification and admission state separate; our app stays on ALB plus tRPC.

B7: DynamoDB deep dive

• DynamoDB connects key design, consistency, indexes and conditional writes to actual email and ticket recovery. It explains the event-date GSI hot-key risk and designs race-safe check-in without claiming exactly-once external effects.

B7: Step Functions deep dive

• Step Functions designs a booking/payment saga with durable waits, callbacks, retry, compensation and expiry races. It explains why our current outbox and independent queues remain enough. All workflow additions are explicitly designed, not built.

B7: SNS deep dive

• SNS separates publish acceptance, subscriber delivery and business completion. It explains raw fan-out, filters, FIFO, current size limits and why subscription DLQs differ from our consumer DLQs.

B7: SQS deep dive

• SQS follows receive, visibility, processing, deletion and redrive. It compares standard/FIFO behavior, explains partial failures and shows real queue settings and recovery limits.

B7: Lambda deep dive

• Lambda explains initialization, invocation models, concurrency, networking, packaging, partial failures and the two real workers. It separates account history from current deployment state and documents the duplicate-email window.
• Deep dives now use the requested longer teaching structure, a shared diagram palette and readable scroll regions. The template and automatic checks follow that structure.
• Light, dark and 375 px checks cover every diagram before each page is committed.

Deployment protection and a Lambda deletion incident

• CD records the owner’s dev rule: only main may deploy, with Prevent self-review OFF while there is one reviewer. A second person approving production deploys is the team practice. The owner will configure GitHub; the book does not claim the setting was checked.
• A new incident explains why permission to delete a Lambda trigger is insufficient when Pulumi must read it while waiting. The recorded CD error checks GetEventSourceMapping against *, which the existing mapping ARN grant cannot cover. The case explains the separate read grant, retained regional Deny and tests without claiming recovery.

B5 review + B6: practice explaining and defending the design

• 52 scenarios each start with an interview question, then a short answer, deeper reasoning, three counter-questions and links to the chapter, map and code. The last six explore proposed reminders, check-in, live seats, waiting rooms, multi-region booking and SLOs/tracing; each says clearly that the extension is not implemented.
• 40 flashcards and 24 quiz questions cover Parts 0–6 and the casebook. Reveal answers, choose a part, check explanations and restart. Answers also work as plain HTML; controls and theme selection work when storage is blocked.
• The mock interview has ten three-minute rounds, optional timing, pause/reset and scenario reviews. Keyboard focus follows the next question or round.
• Six casebook pages received a factual review, including the scheduled Lambda and old deployed code. Checks now inspect the service-selected task revision, SNS raw/filter settings and exact console routes. The immutable OIDC subject case labels its denial as representative because the original log was not preserved. Image retention and timeout explanations are more precise.

B5: the casebook

• 25 cases start with a symptom and identify the service, then separate reachability, permissions, passwords and application behavior. Each has a decision diagram, ranked checks, console/CLI/CloudTrail guidance, a fix, prevention and a short interview answer. On phones, decision diagrams scroll sideways with keyboard support so labels stay readable.
• Troubleshoot task startup, unhealthy targets, queues, duplicate emails, S3 uploads, stale caches, rate limits, migrations, deployment identity, Lambda limits and unexpected costs. The scheduled Lambda exercise covers changing policies, object prefixes, encryption and rotated secrets without claiming that job is deployed here.
• Five incident pages cover the immutable OIDC subject, stale deployment approval, a publish-policy denial, CloudFront account verification and the web-vitals fetch bug. The pages distinguish preserved evidence from missing original logs. The web-vitals case includes the owner’s trace and regression result. The policy case separates an unproven propagation guess from a proven stale-deploy policy revert.
• Images and scans explicitly records the difference from the frozen old step notes: the book follows CI’s --ignore-unfixed setting.

B3 + B4 review: precise failure cases and interview answers

• Eight randomly sampled chapters across Parts 2–5 were checked against the implementation, including diagrams, follow-ups and every interview answer.
• Valkey, IAM roles, RBAC and security headers now distinguish outages from lost sessions, injected secrets from AWS permissions, new authorization checks from in-flight work, and nonce trust from a complete XSS guarantee. Three diagrams use clearer vertical layouts.
• SQS and Lambda clarify retention, duplicate emails and a dangerous configuration error: without partial batch reporting, a normal return can delete failed messages too. The map’s related explanations match these corrections.
• Bootstrap explains preserved config, per-stack GitHub settings and DNS after the first CD run. OIDC separates IAM trust from GitHub approval settings and explains the remaining trust in deployment code.
• The DLQ and 5xx runbooks check processing outcomes and the affected API or web route, rather than relying on an empty DLQ or a quiet alarm alone.

B4: Parts 4-6, runbooks, and map fixes

• 20 new path chapters. Part 4 follows a booking after the response: the outbox, SNS fan-out, SQS and the DLQ, the Lambda worker, DynamoDB, S3 and presigned URLs and SES. Part 5 explains delivery, from CI to bootstrapping a new account. Part 6 covers logs, alarms, the dashboard, cost switches and runbooks.
• All runbooks: ten checklists (signal, check, fix, verify) for every alarm, a bad deploy, a refused deploy, a failed migration, a rotated password and turning the environment off or on.
• The glossary and design decisions now cover Parts 0-6.
• The map: the side panel now scrolls on its own, with its tabs always visible. Before, long tabs were cut off. The mouse wheel over the panel scrolls the panel and never zooms the map.
• The map: Fit frames only what the current stage shows, so early stages open zoomed in. The cost budget now sits in an “Account-wide” row with the IAM roles, right under the account. On screens narrower than 1280 px the map opens on the VPC with readable labels; Fit still shows everything.

B2 + B3 follow-up: a real AWS architecture map

• The map now shows where each piece lives: outside AWS (browser, Cloudflare DNS, GitHub Actions), inside the AWS account, inside the VPC with its two AZs, in the public or private subnets, or in an AWS-managed service outside the VPC. Each resource shows the security group it uses as a small dashed label. CloudFront-mode pieces stay faint in their places.
• Arrows go around boxes, are coloured by layer, and draw in when you select a piece. Hover a line to read its rule, for example “TCP 5432 from api-sg”. A role’s permissions light up one by one, each line naming its policy type.
• Moving around: drag, wheel or trackpad zoom around the cursor, pinch, double-click or double-tap, + and − keys, 0 for Fit, arrow keys to move, Esc to close. A minimap appears when you zoom in. Full screen fills the window.
• During a flow, the narration sits in the side panel next to the map, a dot travels along the arrow, and the camera follows the step when it leaves the screen.
• On a phone the map opens as a list of pieces grouped by where they live; “Map view” opens the full-screen map, and the panel slides up from the bottom.
• Wording: a few leftover picture words in the security group, CloudFront and booking chapters became the real terms, for example “API tasks use the security group api-sg”.

B3: the first four parts of the path

• 27 new chapters. How to read and the words we use; the story of one booking and the whole system on one page; AWS foundations from the account to CloudFront; and the app inside, from the API’s layers to security headers.
• Every chapter has a diagram to redraw, the real names and values from the code, a “Break it” table, a 20-30 second interview answer, follow-ups and a checkpoint. Links open the matching piece or flow on the map, and the map now links back to these chapters.
• New: the glossary and the design decisions, covering Parts 0 to 3 so far.

B1 + B2 review: facts and flows re-checked

• A second reviewer checked a random sample of piece panels, connections and permissions against the code, and played every flow on the map in light and dark mode, including a failure branch in each. Everything matched; nothing on the map changed.

B2: explore the map

• The map now grows from stage 0 to 24. Find a piece, select it to zoom, drag to move, or use Fit for the overview. Toggle network, security, IAM, secrets and data connections.
• Every piece has six tabs: a simple explanation, exact connection rules, permissions, failure clues, console/command/code references, and deeper reading. Future pages are clearly labelled.
• Follow booking, search, failing email, sale day, deploy or “Why can it connect?”. Play, pause, change speed, step by hand and open a failure branch. Reduced motion uses manual steps.
• Piece, flow and stage links open the right view. Off-mode pieces stay labelled, and permission highlights keep the full scopes and conditional Deny statements visible in the panel.

B1 review: complete permissions and precise deploy behavior

• The permissions matrix now has 51 permission entries with complete action lists, separate scopes, shared callers in one row, and the bucket rule that refuses HTTP for every caller. Resource-policy rows name both the caller and the target. Broad grants also appear when looking up who can touch an ALB or Service Connect.
• Deploy explanations now cover first-deploy exceptions, migration failures, blocked image overrides and the smoke test’s DNS bypass. Approval depends on the GitHub environment settings.
• The ALB panel explains that invalid header-name fields are removed before forwarding.
• Generated diagrams scroll sideways on small screens so their labels stay readable.

B1: the real words, and the book’s data

• The book now uses the real AWS terms everywhere (security group, inbound rule, task role, target group, event source mapping), in plain sentences. The old story comparisons are gone; Part 2 is now AWS foundations.
• New: Every connection and what allows it and the Permissions matrix, generated from the same data the map will use.
• The initial data covered 71 pieces of MiniTickets, 113 connections with their exact rules, 48 permission entries, 158 “break it” entries and the 6 flows the map will animate.
• For writers: Generated blocks shows the diagrams and tables a page can generate instead of drawing them by hand.

B0: the skeleton

• The book exists: home page, the three layers in the sidebar, and an overview page for every part with its planned chapters.
• Four page templates (path chapter, deep dive, case, scenario) in the Page templates section.
• Read/unread ticks in the sidebar (stored in your browser only).
• pnpm book:check checks pages, links, code references, word limits and diagrams.