9.14 Design a URL shortener: the interview flow (the board 4.0 plan)

Restore point: tag board-3.13 (5 Oct 2026). Everything below is built on branches and goes live only after Bruno has seen it. Codex (gpt-6-astra, high effort) builds; Iris writes the briefs and checks the results.

Bruno's words, 5 Oct 2026 04:49 UTC (the source of truth for this plan)

In an architecture interview. There is usually database schema design to it. and thoughts about databases, what choice of db you would take and why. There is api spec. I didnt know that click worker was lambda, thats very misleading. now i understand. I think after api spec. we have to figure out how do we deal with non-api functionality like lambda. how can we rework that to be less confusing. Maybe Events Functionality. Idk it has to flow. Then the simulations.

The system design portion should not be part of the api spec and all that. It should be its own thing with the simulation of low/medium/high traffic.

After that there should be a button of Chaos Engineering. Where we grab REAL WORLD failure. MANAGEABLE FAILURE THOUGH. Not world ending failure. And see how the system design handles it in a simulation under normal traffic and an animation showing it go down. through explosions or thunderbolts or some cute animation showing something broke.

ASIDE FROM ALL THAT. I think after all that is done. The user unlocks the answers written by you for questions asked to jev/database design and schema/api spec/events functionality(optional)/system design architecture/ system design architecture with Chaos engineering in mind. (i think 2 different designs is important) remember with aws language plus actual name of what the component is. DynamoDB (database) ect.

And thats that. EVERYTHING ELSE thats mainly under building it locally and what not, should be moved to another page. Think of it as a sub segment under 9.14 Design a URL shortener. like - Lab - version of it.

Earlier the same night, about the board as it is: an EVENT is not an API (nobody calls it; a queue hands it work), the panel matching the API's pieces to the drawn boxes is "a turn off" and "doesn't make this flow as good as i wanted", and the board naming a worker without saying it runs on Lambda was "very misleading".

The main page, in the order an interview runs

1. The problem. What the page says today under "Application background" and the sizing. Unchanged.
2. Jev's questions. The interviewer, as today.
3. Data model. The database schema (tables or items, keys, the fields each holds) and the choice of database with the reason for it. New.
4. API spec. Only the endpoints: method, path, what each takes, what each answers (201, 302, 404, 409, 410). No queues, no workers, no stores in this section.
5. Events (optional). Work that no client calls: a queue or stream hands it to a worker. Each worker is named with what it runs on, "Click worker (Lambda)", and says where it takes work from and where it puts it.
6. Simulations. The five scenes, as today, each opening on its two sentences.
7. System design. The drawing, and the heavy test at low, medium and high traffic. Its own section, not inside the API. The board places each piece the API and the events name on a drawn box by itself; it asks the reader only when it cannot tell.
8. Chaos engineering. A button. A real-world, manageable failure (a cache node dies, the database throttles, Lambda is throttled, a queue backs up, one availability zone is slow) hits the reader's design under normal traffic, and an animation shows the part going down (a small explosion or a thunderbolt on the box) and what the design does next. Only failures the model can simulate honestly.
9. Answers. Unlocked once the sections above are done: the guide's own answers to Jev's questions, the data model and schema, the API spec, the events (optional), the architecture, and the architecture again with chaos in mind. Two designs. Every part named the AWS way with what it is: "DynamoDB (database)", "ElastiCache (cache)", "SQS (queue)", "Lambda (worker)".

The Lab page: "9.14 Lab"

Everything about building it locally moves to a sub-page under 9.14: "Build it locally", "Get the code and run the supplied example", "Set up your implementation workspace", "Local components and state to implement", "Implement the assignment", "Demonstrate the completed local result", "Map the local implementation to AWS" and "Provision resources, then connect the application". The main page links to it in one line.

Phases

Rules for every phase

• Branch from board-3.13 or a later tag; never push to main from a worker. Iris merges, runs the release suite, and releases only after Bruno has seen it.
• The tests' scenes and the runner stay correct: a design the simulations pass must keep passing.
• Words follow the guide's rules: plain sentences, no time details where they are not the rule, the AWS name with what it is.