1. Availability vs Consistency

• Availability is about ensuring that the system is always up and running, even if some parts are having problems.

• Consistency is the assurance of getting the most recent data every single time.

For example, you post a comment on LinkedIn. A few minutes later, you try to edit it but can’t find it yet. The system is available, but your data isn’t synced across all regions. Consistency was sacrificed to stay online.

2. Cost vs Performance

• Cost is about keeping infrastructure and operational expenses low, even if it means slower response times or using fewer resources.

• Performance is about speed, responsiveness, and handling high loads but usually at a higher price.

For example, using smaller instances or cheaper storage helps reduce cost, but it might slow down the app under heavy load.

3. Scalability vs Simplicity

• Scalability is about designing systems that can grow with increased users, data, or traffic, often requiring distributed systems, queues, or microservices.

• Simplicity is about keeping the architecture easy to understand, maintain, and debug, usually favoring monoliths, fewer moving parts, and straightforward logic.

For example, microservices scale better, but a monolith is easier to start and maintain early on.

4. Speed to Market vs Technical Debt

• Speed to Market means launching fast to deliver value quickly, get feedback, or beat competitors — even if the solution isn’t perfect.

  Technical Debt is the cost of cutting corners, like poor code quality, lack of tests, or rushed design which can slow you down later when scaling or adding features.

For example, hardcoding configs to hit a release deadline might save time now, but will likely require rework when the system scales.

 

What’s a design tradeoff your team recently debated? What was the most difficult decision to make?