OOP & Design Principles • SOLID PrinciplesMedium⏱️ ~2 min
Liskov Substitution Principle (LSP): Behavioral Compatibility at Scale
The Liskov Substitution Principle requires that implementations honor the behavioral contract of their abstractions so they can be swapped without breaking callers. It goes beyond matching method signatures to include preconditions, postconditions, invariants, and operational characteristics like latency and error rates. If a PaymentProvider interface promises idempotent retries and a new implementation silently double charges on retry, it violates LSP even if the method signature is correct.
At production scale, LSP violations show up as tail latency spikes, elevated error rates, or correctness bugs when a new implementation rolls out. Google Ads real time bidding requires responses within 100 to 120 milliseconds. When a new bidder adapter takes 200 milliseconds, it triggers timeouts and lost revenue even though it implements the interface syntactically. The contract includes the latency Service Level Objective (SLO), not just the method shape. Amazon payment providers must handle circuit breaker policies, rate limits, and idempotency consistently; a provider that fails differently under load violates the operational contract and causes checkout instability during Prime Day peaks at tens of thousands of transactions per second.
LSP also governs exception and error semantics. If one storage backend throws a generic Exception on timeout while another throws a typed TimeoutException, calling code cannot write uniform error handling. Microsoft's Azure logging abstraction ILogger expects implementations to never block the calling thread; a logger that synchronously flushes to disk on every call violates this performance invariant and stalls request threads, inflating p99 latencies across the application.
The tradeoff is that strict behavioral compatibility constrains implementation freedom. A new, faster provider might want to batch requests or use aggressive caching, but if these optimizations change retry semantics or staleness guarantees, they break LSP. Mitigation strategies include contract tests that run against all implementations in continuous integration (CI), canary rollouts at 1 to 5 percent traffic with SLO checks, and capability flags to disable non conforming implementations quickly. When designing abstractions, encode latency budgets, error types, idempotency, and concurrency safety explicitly in documentation and validate them in conformance suites, similar to how Kubernetes validates storage and network plugins.
💡 Key Takeaways
•Beyond signatures to SLOs: Google Ads bidder interface requires 100 to 120 ms response times. A new bidder taking 200 ms violates LSP operationally, causing timeouts and revenue loss even with correct method signatures.
•Error and retry semantics matter: If PaymentProviderA is idempotent on retry but ProviderB double charges, swapping them breaks checkout correctness. Amazon's payment abstraction must encode idempotency as part of the contract.
•Performance characteristics are part of the contract: Microsoft ILogger promises non blocking calls. A logger that synchronously writes to disk on every log statement violates this, stalling request threads and inflating p99 latencies.
•Detect violations with contract tests: Run conformance suites in CI against every implementation, validating latency budgets (p95 < 200 ms), error rates (< 0.5 percent), and idempotency. Fail builds on regression.
•Canary and capability flags for safety: Roll out new implementations at 1 to 5 percent traffic, monitor SLO deltas (latency, errors, throughput), and use feature flags to quickly disable non conforming code before it impacts all users.
•Strict compatibility constrains optimization: A caching provider might improve latency but change staleness guarantees, violating the contract. Balance flexibility with behavioral guarantees by documenting invariants upfront.
📌 Examples
Google Ads RTB: Bidder adapters must respond within 100 to 120 ms and respect rate limits. A bidder that exceeds timeout or double bills on retry violates LSP, causing auction failures and lost revenue at high query per second (QPS).
Azure ILogger: All implementations must be non blocking. A FileLogger that does synchronous disk writes on every call violates the performance contract, stalling application threads and breaking p99 latency SLOs.
Amazon PaymentProvider: Contract specifies idempotency, p95 latency < 400 ms, and circuit breaker compatibility. A new provider that retries non idempotently or ignores timeouts breaks checkout under Prime Day load (tens of thousands of transactions per second).