Lesson 19 · Senior v2 architecture

Mock senior v2 architecture interview pack

A retrieval-first practice pack for turning the whole v2 architecture course into answers you can say clearly under pressure.

Your win: run a realistic senior v2 architecture mock interview on yourself, score the answers honestly, and turn weak spots into a precise revision plan.

In plain English Plain English: answer out loud before checking the answer points. The goal is to practice retrieval and structure, not to reread passively.

The format

This page works best if you treat it like a real interview. Answer first. Then check the points. Then answer again more cleanly.

The answer checklist A strong answer should usually include: (1) the mental model, (2) the key trade-off, and (3) a real repo-grounded consequence or example. If one of those three pieces is missing, the answer usually sounds thinner than you think.

Round 1 · Core architecture vocabulary

These questions test whether the foundation really belongs to you rather than only sounding familiar.

  1. What is the real purpose of ports and adapters?
  2. What is a composition root?
  3. What makes a dependency-inversion leak load-bearing rather than cosmetic?
  4. What does CQRS mean in this repo?
  5. Why is `database.Ext` important?
  6. What does sqlc actually buy the architecture?
Round 1 · Strong answer points
  1. Ports and adapters. The core owns interfaces for what it needs, while concrete DB/transport code implements them from the outside so the dependency direction stays healthy.
  2. Composition root. It is the edge where concrete repos, handlers, and transports are assembled; the core should not own that construction.
  3. Load-bearing leak. It changes who depends on whom — especially when the core imports or constructs concrete infrastructure.
  4. CQRS here. Lightweight separation of command and query handlers; no bus, no event sourcing, direct invocation from controllers.
  5. `database.Ext`. It lets one repo method accept either a pool or a transaction handle, which makes transactional composition practical.
  6. sqlc. It keeps SQL explicit while generating type-safe Go, a querier interface, mocks, and repo-friendly query seams in eureka.

Round 2 · Trade-offs, smells, and design review

This is where the mock starts feeling more senior. Naming the pattern is not enough; the judgment matters more.

  1. Why is the conversationmgmt leak a better teaching example than a random messy file?
  2. Why is Fowler’s CQRS caveat still important here?
  3. Why is sqlc not automatically the right answer for every service?
  4. When does a transport-agnostic handler become a real design win?
  5. What makes a module worth copying versus merely worth studying?
  6. What is the danger of treating architecture purely as folder naming?
Round 2 · Strong answer points
  1. conversationmgmt leak. It is concrete, local, and changes the dependency direction, so it teaches the actual architectural failure mode instead of a vague cleanliness complaint.
  2. Fowler caveat. CQRS adds risky complexity; this repo intentionally keeps the lightweight form because the extra machinery often is not worth it.
  3. sqlc trade-off. Query-heavy services benefit more from generated safety; simpler CRUD services may not earn back the codegen and operational complexity.
  4. Transport-agnostic win. It is valuable when the business logic stays central and wrappers remain thin, so behavior does not drift by protocol.
  5. Worth copying. A module worth copying has healthy seams, clearer wiring, and better boundary discipline — not just cleaner file names.
  6. Folder naming danger. It can hide a broken dependency story behind architecture-themed names.

Round 3 · Repo-grounded architecture reasoning

This round is what makes the mock specific to your actual backend work instead of generic architecture trivia.

  1. Which modules are the best v2 examples in this repo, and why?
  2. What is the eureka read/write asymmetry rule?
  3. Why does constructor-not-literal matter for eureka repos?
  4. How does the repo reuse logic across gRPC, Kafka, and NATS?
  5. Why do v1 and v2 coexist?
  6. How would you explain this architecture honestly in a senior interview?
Round 3 · Strong answer points
  1. Best examples. `system_notification` for CQRS, spike `email` for clean module wiring, and eureka `assessment` for sqlc plus read/write asymmetry.
  2. Read/write asymmetry. Reads may call queriers directly where allowed, but mutating writes must go through repository interfaces so invariants and hooks are protected.
  3. Constructor-not-literal. Eureka repos carry a querier field that the constructor initializes; a bare struct literal leaves it nil and can panic.
  4. Transport reuse. Business logic lives in reusable handlers/subscribers while wrappers do protocol translation and delegation.
  5. v1 + v2 coexistence. It is the migration strategy: new bounded contexts grow in v2 while legacy code is maintained but not expanded.
  6. Senior explanation. Describe it as pragmatic hexagonal/CQRS/sqlc architecture with real strengths, deliberate trade-offs, and a few load-bearing smells you can name honestly.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off or repo-grounded consequence.
3I gave a strong, clear answer with model + trade-off + repo consequence.
Recovery map — where to go next Missed core architecture vocabulary? Revisit Lessons 1–4 and 13–14. Missed CQRS and transaction answers? Revisit Lessons 5–8 and 15. Missed sqlc and synthesis answers? Revisit Lessons 9–12. Missed transport and testing answers? Revisit Lessons 16–17. The point is not to reread the whole course; it is to go back to the exact weak seam.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into durable interview recall.
What are the three ingredients of a strong senior v2 architecture answer?
recall, then click to reveal
A clear mental model, the important trade-off, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior v2 architecture interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.