Lesson 19 · Senior NATS practice
Mock senior NATS interview pack
A retrieval-first mock pack for turning the whole NATS JetStream course into clear, interview-grade answers you can say under pressure.
Your win: run a realistic senior NATS mock interview on yourself, score your answers honestly, and turn weak spots into a focused review plan.
How to get the most out of this page
This page works best if you treat it like a real interview. Answer first. Then check the answer points. Then answer again more cleanly. That rhythm matters because recognition is not the same as recall.
The goal is not to “cover the page.” The goal is to train yourself to say clear, structured answers under time pressure.
In plain English
Plain English: answer out loud before checking the answer points. Recognition is not recall.
The answer checklist
A strong answer should usually include: (1) the model, (2) the main trade-off or risk, and (3) a repo-grounded consequence or example.
The format
- Round 1 · Core model and routing — 6 questions
- Round 2 · Delivery, replay, and safety — 6 questions
- Round 3 · Senior design judgment — 6 questions
- Time target — 60–90 seconds per answer
Round 1 · Core model and routing
- What is the most important difference between core NATS and JetStream?
- Why is subject taxonomy more than naming style?
- What do wildcard boundaries decide besides matching?
- Why does a stream use InterestPolicy here?
- Why is a consumer not the same thing as a subscriber callback?
- Why are most learner-owned consumers push queue groups?
Round 1 · Strong answer points
- Core vs JetStream. Core NATS is at-most-once live pub/sub; JetStream adds persistence, consumers, replay, and at-least-once delivery.
- Subject taxonomy. It shapes wildcard capture, stream boundaries, ACLs, and future fan-out semantics.
- Wildcard boundaries. They define what events get captured and reasoned about together, not just what names match.
- InterestPolicy. The repo wants internal events kept only while interested consumers still need them, not retained as a long replay log.
- Consumer. It is the stateful read cursor with delivery settings, not just the handler function.
- Push queue groups. They fit the repo’s common event-fanout workload with straightforward horizontal sharing.
Round 2 · Delivery, replay, and safety
- How does JetStream become at-least-once here?
- Why is Ack-only handling both simple and limiting?
- Why isn’t Nats-Msg-Id dedup enough by itself?
- What problem does SkipMsgOlderThan solve?
- How does tenant isolation survive the async hop?
- Why is the activity-log path the best contrast example in the repo?
Round 2 · Strong answer points
- At-least-once. AckExplicit means unacked work redelivers after AckWait until the cap.
- Ack-only limits. It is simpler, but it gives up richer failure intent like explicit Nak/Term behavior and a cleaner poison-message path.
- Dedup boundary. Publish dedup does not replace application idempotency or stale-event reasoning.
- SkipMsgOlderThan. It prevents replay storms from reprocessing ancient events that are no longer meaningful.
- Tenancy hop. DataInMessage carries resource_path and user context, and handleMsg re-injects claims before the handler runs.
- Activity-log contrast. It is the one pull consumer, showing batch-oriented flow control rather than the repo’s normal push queue-group shape.
Round 3 · Senior design judgment
- What is the real gap in the repo’s poison-message story?
- What is the real job of a DLQ in this context?
- How would you review whether a subject family is too broad?
- When would you choose pull instead of push for a new JetStream path?
- When should a flow move from NATS to Kafka?
- How would you summarize this repo’s NATS philosophy honestly?
Round 3 · Strong answer points
- Poison gap. Ack-only handling plus no DLQ means poison messages are either retried by timeout or acknowledged away with limited recovery visibility.
- DLQ. Preserve failed-message evidence while letting the main flow continue safely.
- Broad subject family. Ask whether unrelated events now share wildcard, retention, and ownership assumptions they should not share.
- Pull choice. Choose it when the client needs controlled fetch size, batching, and pacing rather than server-driven push.
- NATS to Kafka move. Move when the workload wants a more replayable durable pipeline shape or aligns better with the Kafka data-flow ecosystem.
- Repo philosophy. Fast internal durable eventing with JetStream, envelope-based tenancy and tracing restoration, push queue-group defaults, explicit trade-offs around Ack-only failure handling, and selective Kafka migration where the pipeline shape fits better.
Self-scoring rubric
| Score | Meaning |
|---|---|
| 0 | I could not explain it without notes. |
| 1 | I gave fragments, but the answer was incomplete or fuzzy. |
| 2 | I explained the main idea, but missed the trade-off, risk, or repo consequence. |
| 3 | I gave a strong, clear answer with model + trade-off/risk + repo consequence. |
Recovery map — where to go next Missed core NATS and JetStream? Revisit Lessons 1–4. Missed the golib and delivery model? Revisit Lessons 5–8. Missed repo application and bus choice? Revisit Lessons 9–12. Missed senior judgment? Revisit Lessons 13–18.
Q1. The main rule of this mock pack is…
Retrieval first is what turns recognition into interview recall.
What are the three ingredients of a strong senior NATS answer?
recall, then click to reveal
A clear NATS or JetStream model, the important trade-off or failure risk, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior NATS interview and grade you answer by answer. Ask me.
Sources. This pack synthesizes the whole course into retrieval practice.