Backend Architecture
Middleware and DI: multiple-choice review
Crux Multiple-choice synthesis across the middleware and DI unit — the two axes, the middleware contract, injection scopes, the testing seam, and container resolution.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a judgement you make on a real backend — which axis a problem lives on, what the contract forbids, what lifetime an object should have — not a definition to recite.
Goal
Confirm you can place a problem on the right axis (request vs wiring), reason about middleware ordering and the response contract, choose an injection scope, and read a container failure — the synthesis the six lessons built toward.
Quiz
Completed
A handler is slow on every single endpoint, and separately a billing class is impossible to unit-test without hitting the real Stripe API. On which axis does each problem live?
Heads-up Only the untestable class is a wiring concern. Slowness on every endpoint points at something in the per-request pipeline — the request axis — not at how a class is constructed.
Heads-up The testability problem exists at construction, decided once at startup, independent of any request. It is a wiring-axis (DI) issue, not middleware.
Heads-up Routing only picks which handler runs. Uniform slowness is the pipeline around handlers; untestability is hidden construction. The senior reflex is to name the axis first.
Quiz
Completed
An Express middleware sends res.json(...) on a validation failure and then also calls next(). Under load it intermittently throws 'Cannot set headers after they are sent'. What rule was broken?
Heads-up Order decides what runs around the handler, not this error. The failure is responding twice on one socket — doing both terminate and pass-through in the same middleware.
Heads-up res.json() is unchanged. The defect is calling next() after already sending the response, which causes a second write to a finished response.
Heads-up Body size does not produce this error. It is specifically a second write after the response was already ended once.
Quiz
Completed
A central Express error handler written as (err, req, res) never receives errors even though earlier code calls next(err). Why, and what is the fix?
Heads-up It must be registered last, after all routes — but that is not why this one is skipped. Express skips it because it declares three parameters instead of four.
Heads-up next(err) is the correct way to forward an error. The handler is bypassed purely because its parameter count is three, not four.
Heads-up Centralized error middleware is standard practice. The single reason this one is skipped is its arity — it must take four parameters to be recognized.
Quiz
Completed
Intermittently, user A sees user B's account name. Auth is correct. A service registered as a singleton stores this.currentUser per request. What happened, and what is the cleanest fix?
Heads-up Transient creates many instances but does not cleanly give per-request identity, and it is heavier than simply passing the value. The shared-field race is solved by not storing request state on a singleton.
Heads-up The data layer is correct. The leak is a shared mutable field on a process-wide singleton being overwritten by concurrent requests, not a query defect.
Heads-up That maximizes scope-bubbling cost, recreating the module's graph on every request to avoid a value you could simply pass as an argument. Prefer the stateless singleton.
Quiz
Completed
A behavior-preserving refactor splits one repo.save() into two saves inside a transaction. Final state is identical, yet forty tests go red. What does this reveal?
Heads-up Behavior is unchanged and the final persisted state is identical. The tests broke on call shape, not on any observable defect — that is the signature of over-mocking.
Heads-up Injection created the seam that made the tests possible; the problem is what the tests assert through that seam. State-based assertions would have survived the refactor.
Heads-up Coverage was high — that is the irony. The issue is the kind of assertion (interaction vs state), not the amount of coverage.
Quiz
Completed
An app boots in dev but crashes in prod with 'Nest can't resolve dependencies of UserService'. AuthService now imports UserService, which already imported AuthService. How do you read this, and what is the real fix?
Heads-up forwardRef defers one side's resolution to break the deadlock but preserves the design flaw. A cycle almost always means two classes that should be one, or a missing shared third class.
Heads-up The container is correctly reporting that a circle has no valid construction order. The bug is in the dependency graph, not the resolver.
Heads-up Module boundaries are not the cause — two classes in one module can still cycle. The problem is the dependency cycle itself, which only an acyclic redesign removes.
Recap
The unit’s through-line is one habit: name the axis, then apply its discipline. The request axis (middleware) demands one ending per middleware and a deliberate order; error middleware needs four parameters. The wiring axis (DI) means classes declare needs and a composition root supplies them — default to stateless singletons, escalate scope only when forced, and read test pain as a design signal (mock the boundaries you don’t own, fake what you do). A container is that composition root mechanized: it topologically sorts the graph, refuses cycles, and should fail fast at boot. Every question here resolves back to those two axes and the cost each carries.