Chapter 9: When LLD Contradicts Its Own HLD

Why this matters

Chapter 7 covered the general discipline of keeping LLD faithful to HLD intent. This chapter goes deeper on the specific, sharper failure mode where an LLD document doesn't just drift from the HLD's spirit but actively contradicts a specific, stated HLD decision — a more serious, more concrete problem than drift, and one that a careful review process should reliably catch before implementation begins.

What a genuine contradiction looks like, concretely

[BEGINNER] A contradiction is stronger than drift — it's a specific LLD statement that's factually incompatible with a specific HLD statement, not just a vague sense that intent has shifted:

HLD states: "The Booking Service and Payment Service communicate
ASYNCHRONOUSLY via an event queue, specifically so that a slow payment
provider does not block the booking confirmation response."

LLD states (contradicting this): "BookingService.confirmBooking()
calls PaymentService.chargeCard() directly and SYNCHRONOUSLY, waiting
for the charge to complete before returning a booking confirmation."

This is not ambiguous drift -- it's a direct, factual contradiction.
If both documents are approved as-is, an implementer following the LLD
literally builds something the HLD explicitly said should not happen,
and the exact latency-coupling problem the HLD's async decision existed
to prevent gets reintroduced.

Why contradictions happen even with careful review

[SENIOR INSIGHT] Contradictions aren't usually caused by carelessness — they typically happen because HLD and LLD are often authored (or at least worked on in detail) by different people, at different times, sometimes weeks apart, and the LLD author may not have the HLD's exact wording in front of them while making a locally-reasonable-seeming implementation choice. This is precisely why Chapter 7's practice of explicitly referencing the specific HLD section an LLD document is built against exists — it's a structural mitigation against exactly this "different author, different time, lost context" failure mode, not just a nice-to-have documentation habit.

A systematic process for catching contradictions during review

[IN PRACTICE] Rather than relying on a reviewer's memory of the HLD while reading an LLD document (unreliable, especially for a complex system with many HLD decisions), a more systematic approach:

## LLD review checklist addition: HLD consistency check
1. List every HLD decision that constrains THIS specific component
   (communication mechanism with other components, database technology,
   consistency requirements) -- pull these directly from the HLD document,
   don't rely on memory.
2. For EACH listed constraint, find the specific LLD statement that
   should be consistent with it, and verify explicitly that it is.
3. Any LLD statement that can't be matched to a consistent HLD
   constraint, OR that appears to contradict one, gets flagged
   explicitly as a REVIEW BLOCKER -- not a minor note, since implementing
   against a contradictory LLD guarantees rebuilding it once the
   contradiction is eventually discovered (ideally during review,
   rather than after implementation or, worse, in production).

Resolving a found contradiction: back to Chapter 7's distinguishing question

[SENIOR INSIGHT] Once a contradiction is found, Chapter 7's core distinguishing question applies directly: is the LLD's contradictory choice revealing a genuine flaw in the HLD (in which case the HLD should be revisited and explicitly updated), or is it an implementation convenience that should be corrected to conform to the HLD's still-valid original intent? A contradiction discovered during review is actually the best-case timing for this determination — far better than discovering it during implementation (wasted coding effort) or in production (a live incident, potentially, if the contradiction concerns something like the async/sync latency-coupling example above).

Common mistakes

1. Relying on a reviewer's memory of the HLD rather than a systematic, explicit cross-check when reviewing an LLD for consistency — memory is unreliable, especially for complex systems with many HLD decisions to track simultaneously.
2. Treating a found contradiction as a minor note rather than a review blocker, allowing implementation to proceed against a design that's already known to be internally inconsistent.
3. Assuming contradictions indicate carelessness or incompetence, rather than recognizing the realistic, structural cause (different authors, different times, HLD context not immediately at hand) — this framing matters because the fix (explicit HLD-referencing practices, Chapter 7) addresses the structural cause, while blaming individuals doesn't.
4. Resolving a found contradiction unilaterally without applying Chapter 7's genuine-flaw-vs-convenience distinction, missing the chance to correctly determine whether the HLD or the LLD is the one that actually needs to change.

Discussion / interview questions

1. "What's the difference between LLD 'drifting' from HLD intent and LLD actively 'contradicting' the HLD?" Strong answer: Drift is a gradual, cumulative divergence from the HLD's spirit through many individually-reasonable-seeming choices; a contradiction is a specific, factual incompatibility between a specific LLD statement and a specific HLD statement — a sharper, more concrete, more directly detectable problem.

2. "How would you systematically check an LLD document for consistency with its HLD, rather than relying on memory during review?" Strong answer: List every HLD decision that constrains the specific component, pulled directly from the HLD document; for each one, explicitly verify the corresponding LLD statement is consistent with it — flagging any LLD statement that can't be matched or appears to contradict a listed constraint as a review blocker.

3. "Why do HLD-LLD contradictions happen even on teams with careful engineers and review processes?" Strong answer: HLD and LLD are often authored by different people at different times, and an LLD author may make a locally-reasonable implementation choice without the HLD's exact wording immediately in front of them — a structural, not a competence, cause, which is why structural mitigations (explicit HLD-referencing) are the effective fix.

4. "You find that an LLD document contradicts a specific HLD decision during review. What would you do?" Strong answer: Flag it as a review blocker rather than a minor note, then apply the genuine-flaw-vs-convenience distinction (Chapter 7) to determine whether the HLD needs to be revisited and updated, or whether the LLD needs to be corrected to conform to the HLD's still-valid original intent.

Chapter summary / cheat sheet

• A contradiction is a specific, factual incompatibility between an LLD statement and an HLD statement — sharper and more directly detectable than gradual intent drift (Chapter 7).
• Contradictions typically arise structurally (different authors, different times, HLD context not immediately at hand) rather than from carelessness — the fix is a structural mitigation (explicit HLD-referencing), not blame.
• Use a systematic checklist during LLD review: list HLD constraints for the component, verify each against the corresponding LLD statement explicitly, rather than relying on a reviewer's memory.
• A found contradiction is a review blocker, resolved by applying the genuine-flaw-vs-convenience distinction — catching it during review is far cheaper than discovering it during implementation or in production.

---