Lesson 18 · Senior v2 architecture

Senior v2 architecture interview questions

High-signal architecture, trade-off, and review questions — with the answer shape that sounds like someone who has actually lived in this codebase.

Your win: answer common senior architecture questions in a way that connects the canon to the real strengths and smells in this repo, instead of giving textbook-only answers.

In plain English Plain English: strong architecture answers do not stop at naming the pattern — they explain the trade-off, the failure mode, and the repo-specific evidence.

The problem: pattern words are cheap

Anyone can say “hexagonal,” “CQRS,” or “clean architecture.” The harder and more valuable answer is to explain what those words change in review, testing, transactions, and migration strategy.

The answer recipe Start with the mental model, then name the practical trade-off, then finish with the repo-grounded consequence or example.

Question bank

Question	Best answer shape
What is the point of ports and adapters in this repo?	To keep the business layer depending on interfaces it owns so transports and DB code stay swappable and the core stays more testable.
What is the strongest architecture smell you have seen here?	The conversationmgmt core→infra leak, because the core imports and constructs postgres repos directly, which breaks the dependency direction.
Why is there no CQRS bus here?	Because the repo chose the lightweight form: separate command/query handlers for clarity, but no mediator or event sourcing unless the complexity truly pays off.
What is the real role of `database.Ext`?	It is the seam that lets one repo method accept either a pool or a transaction handle, which makes transaction composition practical across handlers and repos.
Why not use sqlc everywhere?	Because it is a trade-off; query-heavy services benefit more from the generated safety, while simpler CRUD services may not earn back the codegen cost.
What makes a composition root healthy?	Concrete construction lives at the edge, while the core stays focused on behavior and owned abstractions.
Why do transport-agnostic handlers matter?	They let the same business logic be reused across gRPC/Kafka/NATS while keeping protocol wrappers thin.
How do you know a seam is real?	The testing strategy becomes obvious and local: repo mocks for usecases, usecase mocks for transports, DB-focused tests for repos.
Why do v1 and v2 coexist?	Because gradual migration is the strategy; new bounded contexts grow in v2 while legacy code shrinks by attrition rather than through one rewrite.
What is the most load-bearing local rule in eureka?	Read direct through queriers is allowed, but mutating writes must stay behind repository interfaces so invariants and hooks are not bypassed.

Anchor — what strong answers sound like here The strongest answers in this repo mention concrete things: conversationmgmt leaks, `system_notification` as the canonical CQRS module, `assessment` as the best sqlc example, `.claude/rules/*.md` as the real spec, and `database.Ext` as the tx seam.

Use the local canon and the external canon together

Good interview answers here come from both: Cockburn/Fowler/sqlc/Three Dots Labs, plus the repo’s verified maps and conventions.

→ Senior backend playbook
→ Resources

Check yourself (from memory)

Q1. A strong senior architecture answer usually includes…

That structure makes the answer sound like engineering judgment rather than vocabulary recall.

What are the three parts of a strong senior v2 architecture answer?

recall, then click to reveal

(1) the mental model, (2) the key trade-off, and (3) the repo-grounded consequence or example.

When you are ready, do not just reread this page — go to the mock pack and answer out loud. Ask me if you want me to run it live.

Sources. Repo playbook and resources.