When to formalize a cross-cutting concern?

WHAT THIS TESTS: This question probes your senior-level judgment on architectural trade-offs, specifically the tension between DRY principles and the costs of coupling. It tests if you can apply a nuanced decision-making framework in an agile, emergent design context, rather than applying a dogmatic rule. The interviewer is looking for your understanding of volatility, risk, and the organizational costs of shared code.

A GOOD ANSWER COVERS: A strong answer presents a decision-making framework. First, acknowledge the "Rule of Three" as a starting point: tolerate duplication until the third instance appears. Second, introduce the core decision criteria for moving to a shared solution: high volatility (the logic changes often), high complexity or risk (e.g., authentication, payments), or a high cost of inconsistency across teams. Third, contrast this with when duplication is acceptable: low volatility, low risk, and when the overhead of a shared solution (ownership, versioning, distribution) outweighs the benefits. Fourth, describe the process of introducing a shared solution, such as a timeboxed spike and clear ownership.

COMMON WRONG ANSWERS: A major red flag is a dogmatic, one-size-fits-all answer. "You should always abstract to avoid duplication" is a junior answer that ignores the high cost of premature abstraction, coupling, and cross-team dependencies. Another red flag is the opposite: "Shared libraries are always bad." This ignores the massive maintenance burden of updating a critical, scattered concern (like a security patch) in dozens of places. A weak answer also fails to mention the organizational aspect (Conway's Law) and the cost of coordination.

LIKELY FOLLOW-UPS: "Describe a time you argued for duplication. What was the outcome?" "How do you manage the lifecycle and versioning of a shared library once it's created?" "What if the teams can't agree on a common interface for the shared solution?"

ONE CONCRETE EXAMPLE: Imagine three microservices all needing to report metrics. Initially, each team implements a simple client for a metrics backend. This is fine. But then, we need to add standardized labels (e.g., region, cluster_name) to every metric for a new observability platform. The requirement is volatile and consistency is critical. Updating all three services is slow and error-prone. This is the trigger to invest in a shared, versioned metrics library that handles the standardized labeling, which the three teams can now adopt. The cost of coordinating the library is now less than the cost of mis-implementing or forgetting the labels.