ACID, SOLID, and Common Design Patterns: A Software Design Reference

Common Mistakes and Interview Traps

• Confusing Consistency (ACID) with consistency in the "our data means what we think it means" sense. ACID's Consistency is about the database's own declared constraints — it does not catch a transaction that's logically wrong but constraint-valid.
• Assuming a stronger isolation level is always safer with no downside. Serializable prevents every anomaly but does so through heavier locking — real systems pick the weakest level that's actually safe for a given operation, not the strongest available.
• Doing multiple related writes without wrapping them in one transaction — the most common real-world way atomicity gets silently lost, not a misunderstanding of what a transaction does once you're inside one.
• Treating Liskov Substitution as "subclass compiles without errors." Square extends Rectangle compiles fine; it still violates LSP because it breaks a caller's reasonable behavioral assumptions about the base type.
• Confusing Dependency Inversion (the principle) with Dependency Injection (a technique for satisfying it), or with a DI container (a tool that automates the technique). You can satisfy DIP by hand, with no container, by passing interfaces into constructors.
• Reaching for Singleton for anything global-feeling, when a DI container's own singleton-lifetime service registration gives the same "exactly one instance" guarantee with the dependency staying visible and testable.
• Using inheritance for behavior that actually varies along more than one independent axis — the sign it's time for composition (Strategy, Decorator) instead of a deeper subclass hierarchy.
• Forgetting to unsubscribe an Observer, leaving a listener referenced forever by a long-lived subject — a quiet memory leak with no thrown error to point at it.
• Treating a shallow Clone() as a deep clone in the Prototype pattern — reference-type fields (lists, nested objects) are shared with the original unless the clone logic explicitly copies them too.

SQL transactions and constraints in more depth are covered in the site's SQL posts — see SQL Fundamentals: Joins, NULL, Aggregate Functions, and Subqueries and Understanding SQL Indexes and Query Performance for how these same constraint and concurrency concepts show up in query design. Practice spotting these principles and patterns — including several "which principle does this violate" scenarios — in the code lab.