Shared Solution vs. Duplication for Cross-Cutting Concerns

WHAT THIS TESTS: This question tests your ability to make pragmatic architectural trade-off decisions in an agile or emergent design environment. The interviewer is not looking for a textbook definition of a cross-cutting concern, but for a nuanced decision-making framework. They want to see how you balance short-term velocity (allowing duplication) against long-term maintainability and consistency (creating a shared solution). It's a test of senior-level judgment, not dogmatic rule-following.

A GOOD ANSWER COVERS: A strong answer presents a framework for this decision. First, state that duplication is often acceptable or even preferable initially, aligning with YAGNI (You Ain't Gonna Need It) principles. This avoids premature, and often incorrect, abstractions. Second, introduce a trigger for re-evaluation, most commonly the 'Rule of Three'. Once a pattern is duplicated for the third time, it's time to formally consider abstraction. Third, describe the evaluation criteria for that decision. This should include: 1) Volatility: How stable is the requirement? Abstracting unstable logic creates a bottleneck. 2) Cost of Inconsistency: What is the business impact if implementations diverge? An inconsistent authentication check is a security flaw; an inconsistent logging format is an inconvenience. 3) Complexity: Is the logic trivial or complex? The more complex, the more value in a single, well-tested implementation. 4) Organizational Fit: Does a team have the charter and resources to own and maintain a shared solution?

COMMON WRONG ANSWERS: The most common red flag is dogmatism. One wrong answer is the 'DRY Purist' who insists all duplication must be eliminated immediately, ignoring the high cost of creating, versioning, and distributing a shared library and the coupling it introduces. The opposite is the 'Decoupling Absolutist' who argues for permanent duplication to maintain service independence, ignoring the massive operational cost and risk when a critical change (like a security patch) must be applied across dozens of repositories. Another failure is ignoring the 'emergent design' context and proposing a large, upfront shared framework before the requirements are stable.

LIKELY FOLLOW-UPS: Expect follow-ups that force you to apply your framework. For example: 'Let's say you have five microservices that all need to report metrics. Walk me through your decision process.' or 'You've decided to build a shared library for authentication. How do you manage its versioning and rollout without blocking all five consumer teams?' Another common one is, 'What happens when two teams have a legitimate disagreement on how the shared solution should work?'

ONE CONCRETE EXAMPLE: Imagine two services need to validate an incoming JWT. Initially, each team implements its own validation logic, perhaps by copying a 25-line utility function. This is fast and decoupled. When a third service needs the same logic, the 'Rule of Three' is triggered. We evaluate: the volatility is low (JWT specs are stable), but the cost of inconsistency is catastrophic (a validation error is a P0 security vulnerability). The complexity is moderate and easy to get wrong. The conclusion is clear: the high cost of inconsistency justifies the effort to create a formal, shared authentication-validation library that becomes a mandatory dependency for all services handling these tokens.