Client application
Backend & Runtime / Knowledge library
Don't Repeat Yourself (DRY)
Keeps each piece of knowledge represented by one authoritative source
Why learn Don't Repeat Yourself (DRY)?
It prevents duplicated rules from drifting apart
The problem it solves
It reduces inconsistent maintenance of the same decision
Where it came from
Don't Repeat Yourself (DRY) is a software design principle that keeps each piece of knowledge represented by one authoritative source. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Don't Repeat Yourself (DRY) and distinguish it from a neighboring concept.
- Choose a realistic task where Don't Repeat Yourself (DRY) is appropriate.
- Identify a failure mode caused by misusing Don't Repeat Yourself (DRY).
- Interpret a small design or result involving Don't Repeat Yourself (DRY).
- Explain one tradeoff or limitation of Don't Repeat Yourself (DRY).
Documentation and sources
- Software Engineering at Google (abseil.io)
Connect the ideas
Explore next
Real World Example
Centralized Tax Calculation Service
A multi-regional e-commerce platform managing diverse international tax regulations.
The business problem
The engineering team maintained redundant tax calculation logic across the web storefront, mobile application, and backend order processing service. When a regional tax rate changed, developers frequently updated one service but missed others, leading to inconsistent checkout totals and compliance risks.
How this topic solves it
By applying the Don't Repeat Yourself (DRY) principle, the team refactored the tax logic into a single, authoritative microservice. All client applications now delegate tax computation to this central source of truth, ensuring that any legislative update is applied globally by modifying only one codebase.
- Identify redundant tax calculation functions across distributed codebases.
- Extract the shared logic into a standalone, versioned API service.
- Implement a unified interface for all clients to request tax calculations.
- Deprecate and remove local tax logic from individual service repositories.
- Establish a single CI/CD pipeline for the tax service to ensure consistent deployment.
This diagram illustrates the transition from redundant local logic to a centralized authoritative service.
Client application
Authoritative source of truth
Backend service
- Web Storefront → Requests tax calculation → Tax Service
- Mobile App → Requests tax calculation → Tax Service
- Order Processor → Requests tax calculation → Tax Service
Expected business outcome
The platform achieves consistent tax reporting across all channels, significantly reducing the risk of compliance errors and minimizing the maintenance burden of updating multiple codebases simultaneously.
Limitations and checks
The primary trade-off is the introduction of a single point of failure and increased network latency for tax lookups. To check for this, monitor the service's availability and response time metrics to ensure the centralized dependency does not degrade the user experience during peak traffic.