Template: deep dive

In 1 minute

Show what happens to one MiniTickets request or event. Name the AWS service and explain each new term simply. Say whether the implementation exists or is designed only. State the most important reliability limit.

Picture it

Where it sits

Use the shared data for implemented names and permissions. Label every arrow with the operation and authorization. Proposed pieces are dashed and say “(designed, not built)”. Link to the nearest implemented piece when the proposed service has no map entry.

flowchart LR
  A["API"]:::app -->|"publish: task role sns:Publish"| S["SNS"]:::service
  S -->|"deliver: subscription + queue policy"| Q["SQS"]:::aws

Legend: purple = this service; teal = app; blue = AWS; amber = IAM; red = failure; dashed = designed, not built.

Open in the map →

How it works

1. Start with the actual trigger and show the first operation.
2. Explain each following operation and who authorizes it.
3. Show success, acknowledgement and retry ownership.

sequenceDiagram
  participant A as API
  participant S as SNS
  participant Q as SQS
  A->>S: Publish, task role
  S->>Q: SendMessage, subscription + queue policy
  Q-->>S: Message accepted

Legend: participants are the app and AWS services; arrows show requests and acceptance.

Under the hood

Explain the mechanism, durability, concurrency and retry boundary in plain sentences.

Limits and numbers

At the time of writing; check the AWS docs. Link the primary source beside each number.

Setting	Value	Source
One implemented setting	Copy the exact code value	Real code reference

In MiniTickets

Say explicitly whether it is implemented or designed only. Link real files and distinguish committed switches from verified running resources.

Connections

List the caller, operation, IAM role, resource policy, trigger and network requirements.

When it fails

flowchart TB
  E["Delivery rejected"]:::failure -->|"retry policy"| R["Retry"]:::service
  R -->|"attempts exhausted: configured redrive"| D["Subscription DLQ"]:::failure

Legend: purple = service retry; red = delivery failure.

Give three to five symptoms with causes and practical fixes.

At 10x / 100x

Explain what saturates first and show how to budget capacity instead of assuming unlimited scale.

Common interview traps

• A precise wrong answer and its correction.
• Another subtle boundary or service comparison.

Design question

Ask a realistic MiniTickets question. Give the model answer and a small diagram.

flowchart LR
  A["API"]:::app -->|"publish: task role sns:Publish"| S["SNS"]:::service
  S -->|"fan-out: subscriptions + queue policies"| Q["Independent SQS queues"]:::aws

Legend: teal = app; purple = this service; blue = buffered consumers.

Say it in an interview

Say it like this (20-30 seconds)

Write a 45-85-word answer. Explain the mechanism, MiniTickets use, retry ownership, one trade-off and one limit. Use the exact AWS terms the reader should say aloud.

Follow-ups

How does success get recorded?

Explain the acknowledgement boundary.

What can be repeated?

Explain duplicate delivery and business effects.

What fails first?

Explain a common production symptom.

What changes with traffic?

Explain the limiting dependency.

Why choose this service?

Compare one realistic alternative.

Remember it

• The first core fact, in one plain sentence.
• The second fact connects a setting to its failure mode.
• The third fact states a guarantee and its boundary.

Advanced: Console, safe CLI and extra detail

Include read-only commands, console paths and details that are optional for a first reading.

Checkpoint

Answer these without scrolling up. If one feels hard, reread that section.

1. What starts the flow?
2. What authorizes the next operation?
3. Who owns retries?
4. What breaks first at scale?
5. Which parts are implemented in MiniTickets?

Redraw it from memory: the main diagram from memory

Try this: Inspect one setting in the code or use a read-only console view.

Mark this page as read