Explain a diagram you can't parse.
Paste the image or describe it. Get back the plain-English walk-through that tells you what the arrows mean, what's async, and where the load actually lives.
You've been sent an architecture diagram, a data-flow chart, or a state machine. It's dense and you don't know where to start reading. This prompt reads it aloud in the right order.
THE PROMPT
Explain this diagram to me. I'll either attach the image or describe the boxes and arrows in text. Structure your explanation as: **Start here** Which box or node the reader should look at first, and why (usually the entry point of data or user interaction). **The main flow** Walk through the diagram in reading order. For each hop, say what's actually happening (synchronous call? async message? database read?). Don't just name the components — explain what the arrow means. **What's easy to miss** The one or two things about this diagram that would confuse a first-time reader — an implicit assumption, an unlabelled arrow, a subsystem that's doing more work than it looks like. **Where the load lives** Which single component would be the bottleneck if traffic doubled, and why. If any part of the diagram is genuinely ambiguous (the arrow direction, the missing label), say so — don't guess. Diagram: [ATTACH IMAGE OR DESCRIBE HERE]
**Start here**
The client (top-left box). User requests originate here and cascade through the system.
**Main flow**
- Client → API gateway (sync HTTPS): the gateway does auth and rate-limiting.
- API gateway → Order service (sync gRPC): the actual business logic.
- Order service → Payments service (async, via SQS): this is the important async hop — the order is confirmed to the user before payment settles.
- Payments service → Postgres (sync): writes the transaction.
- Payments service → Webhook (async, retry queue): notifies external partners.
**What's easy to miss**
The arrow from Order service to Payments is dashed — it's async. This means the user's order-confirmation email fires before payment is actually confirmed. Under Payments outages, users see success but the order can later fail.
**Where the load lives**
Postgres. Every request path terminates in a write. The read replicas in the diagram are only used by the Analytics service; the customer-facing path uses the primary. Doubling traffic here means doubling primary-Postgres write load, and that's the first thing that will fall over.