Diagrams

Works like Lucidchart or draw.io. Diagram how a feature really works, from the request to the database.

Today's setup for appointment booking

A patient opens appointment booking in the browser. Every request goes to our load balancer first.
The load balancer spreads requests across two app servers, app-1 and app-2.
To read, an app server checks the Redis cache first. On a miss it reads from the primary database and fills the cache.
Every write goes to the primary Postgres database.
After a write, the app server puts a job on the jobs queue. A worker takes jobs off the queue, sends the confirmation text, then records that it's done in the primary database.
Draw each arrow the way the request or the data moves.

QuickCruit Diagrams

Appointment booking, today

A blank page

Pick a shape from the library, then click here to place it. Drag from the dot on a shape's edge to connect it to another.

Scroll or space-drag to pan. Ctrl and scroll, or pinch, to zoom.

Questions from Hannah

1. A patient saves a change. Where does that write land?

2. A read misses the cache. Where does the app server read from next?

3. The worker is down for an hour. What happens to people using the feature?

Software engineering

Draw the system you just joined

Before anyone proposes a change to appointment booking, the design review needs the current state on one page, and I'd like you to draw it. My notes on how it runs today are below, in the order a request travels.

Every part on the canvas, one arrow per hop, pointing the way the request or the data moves. Then the three questions underneath. HIPAA reviewers will read this diagram eventually, so draw it for someone who has never seen the system.

Lakeshore Family Health is a made-up company. A practice scenario, built for you.

Draw every part from Hannah's notes, each with a label
Connect them the way requests and data flow
Answer the 3 questions under the canvas