LearningTree

Design Tactics & Strategies
for Quality Goals

Principles, patterns, and solution strategies for achieving performance, adaptability, and high availability in software architecture.

Chapter One · Quality Goals

Design Strategies for Achieving High Performance

 →Develop high-level solution strategies in parallel to detailed concepts
→Principles and patterns support the creation of a solution strategy
→However, there is no single approach that guarantees a suitable solution
 

🖥️

Additional Hardware

Scale out with load balancers & multiple server instances

📡

Reduce Communication

Caching, batching & minimising inter-component calls

🔀

Adjust Distribution

Reduce or increase sharding based on workload

🔧

Reduce Flexibility

Trade configurability for raw performance

📊

Load Testing

Continuous performance benchmarking & regression checks

⚡

Energy Trade-off

High-end hardware & parallelism at the cost of energy

Strategy 1 — Additional Hardware

Adding More Hardware

Scale out by deploying additional servers behind a load balancer to distribute incoming client requests across multiple application server instances.

Horizontal Scaling — Load Balancer distributes requests across server instances

Horizontal Scaling: Client → Load Balancer → Web Application Servers (multiple instances) — distributes incoming traffic to handle increased load without upgrading individual machines.

Strategy 2 — Reduce Communication Between Components

Reduce Inter-Component Communication

Minimize the number of calls between system components to reduce latency overhead. Common solutions include caching and batching.

⚠ Problem — N individual calls create high latency overhead

a. Cache — Solution

Add a cache layer between the web app and backend services
Reduces repeated calls to downstream microservices
Returns pre-computed responses for common queries

Cache Layer — HIT returns instantly, MISS fetches from backend

b. Batch — Solution

Group multiple requests into a single call to the backend
Avoids: N individual calls → 1 batched call
Useful for bulk data operations and report generation

Batch Aggregator — N requests bundled into 1 backend call

Strategy 3 — Reduce or Increase Distribution

Distribute via Sharding

Increase distribution by sharding data across multiple storage nodes, enabling parallel fetching and improved throughput.

Sharding by client_id — Product Reviews distributed across parallel shards

Real-world example: Sharding a Product Reviews service by client_id — each shard handles a subset of clients, enabling parallel fetching and improved throughput.

Strategy 4 — Reduce Flexibility of the System

Trade Flexibility for Speed

Flexible systems that make external config/database calls at runtime are slower. Where possible, replace with hardcoded constants to eliminate I/O on the hot path.

❌ Flexible (Slow) — External calls on every transaction

public boolean processTransaction(String type, double amount, String currency) {
// Reads from JSON config — external call each time if (amount < config.getJSONObject("minimumAmount").getDouble(currency)) {
return false;
  }
// Database call on every transaction double fee = database.getCurrentFee(type, currency);
  ...
}

✓ Optimized — Hardcoded constants, zero I/O

public class TransactionProcessor {
private static final double MINIMUM_AMOUNT_USD = 10;
private static final double WITHDRAWAL_FEE_USD = 2;
private static final double TRANSFER_FEE_USD = 3;
public boolean processTransaction(String type, double amount) {
if (amount < MINIMUM_AMOUNT_USD) return false;
double fee = type.equals("withdrawal") ? WITHDRAWAL_FEE_USD : TRANSFER_FEE_USD;
    ...
  }
}

Strategy 5 — Perform Load Tests

Continuous Load Testing

Optimizing one/multiple components once is good, but systems constantly evolve
Optimizations may be negated by new changes
Performance load testing must be done often and regularly

Strategy 6 — Compromise on Energy Efficiency

Trade Energy for Performance

High-End Hardware

Performance increase: +50%
Energy consumption increase: +150%

Disable Power Mgmt

CPU runs at maximum speed always
Cost: higher energy consumption

Increase Parallelism

Running on multiple GPUs
Distributing computation across multiple computers

📋 Chapter 1 — Summary

Six strategies work in concert to achieve high performance — from hardware scaling to code-level optimizations
Additional hardware & load balancing — scale horizontally to handle more load
Cache & batch to reduce communication overhead
Sharding for increased distribution across nodes
Reduce flexibility — eliminate I/O on hot path for speed
Regular, continuous load testing — verify performance under realistic conditions
Compromise energy for parallelism & speed

Chapter Two · Quality Goals

Design Strategies for Achieving Adaptability & Flexibility

Adaptability and flexibility are achieved by keeping changes local, decoupling components, and making conscious decisions about where the system needs to be flexible.

🎯

Determine Flexibility

Identify where the system needs to adapt — functionality, technology, or environment

📂

Configuration Files

Externalise settings so changes don't require recompilation

📌

Keep Changes Local

Encapsulate change behind stable interfaces

🔗

Decouple Components

Facade & Strategy patterns to isolate third-party & algorithm dependencies

🧬

Polymorphism

Program to interfaces — swap implementations without touching callers

🔒

Information Hiding

Expose only what's needed — hide internal details behind module boundaries

Determine Where the System Needs to Be Flexible

Functionality

Strategy Pattern — swap algorithms/behaviors at runtime
Feature Flags — toggle features without redeployment

if (config.isEnhancedProfileEnabled()) {
displayEnhancedUserProfile(user);
} else {
displayBasicUserProfile(user);
}

Data Structures / Data Model

Schemaless formats (JSON) — evolve without migrations
NoSQL Databases (MongoDB) — flexible document structures

Third-Party Software & External Interfaces

Facade Pattern — decouple from complex third-party libraries
Swap providers without changing internal code

User Interface & Target Platform

Responsive Design — adapt to screen/device
Cross-platform languages (Java, Python)
Containerization (Docker) — platform independence

Flexibility in Functionality — Strategy Pattern

Pattern: Define a family of algorithms (PaymentStrategy), encapsulate each one (CreditCard, PayPal, BankTransfer), and make them interchangeable via a common interface.

Benefit: Add new payment types (e.g., CryptoPayment) without modifying the PaymentProcessor class — open/closed principle.

interface PaymentStrategy {
void pay(double amount);
}
class CreditCardPayment implements PaymentStrategy { ... }
class PayPalPayment implements PaymentStrategy { ... }
class BankTransferPayment implements PaymentStrategy { ... }
class PaymentProcessor {
private PaymentStrategy strategy;
void process(double amount) { strategy.pay(amount); }
}

Facade Pattern — Decoupling from Third-Party Libraries

Problem: Your WebApplication is tightly coupled to a complex Third-Party Storage Library (Credentials, ConfigurationManager, DataStorage). Changing the vendor requires massive refactoring.

Solution — StorageFacade: Introduce a Facade between your application and the third-party library. The application only knows the Facade's simple interface. The complex library implementation is hidden and swappable.

Use Configuration Files

Environment Configs

dev.config — development environment settings
qa.config — test/QA environment settings
prod.config — production environment settings
Load at runtime — no recompilation needed

Application Resources

threadPool — corePoolSize, maximumPoolSize
databaseConnectionPool — maxPoolSize, timeouts
cacheSettings — maxEntries, eviction policy, TTL
messageQueue — maxQueueSize, deliveryTimeout

// external-service.config
thirdPartyService:
  apiKey: "123456789abcdefg"
baseUrl: "https://api.example.com"
authMethod: "Bearer"
additionalConfig:
    timeout: 30
retryPolicy: "exponentialBackoff"
maxRetries: 3

Keeping Changes Local

Monolith — Tight Coupling

Changes to Video Catalog propagate to Payment Processor
Currency Conversion Data is a shared dependency
A change to streaming video formats requires testing the entire system

Microservices — Changes Stay Local

Web App → API Gateway → Microservices A–E
Each microservice has its own database
Changes to Service A don't affect Services B–E

Polymorphism — Flexible by Design

Concept: Allows objects of different classes to be treated as objects of a common superclass. Enables flexibility to perform the same action on different objects with different implementations.

Interface Notification with a send() method
Implemented by: EmailNotification, SMSNotification, AppNotification
Easily extendable: add WatchNotification without changing callers

interface Notification {
void send(String message);
}
class NotificationService {
void sendAnnouncement(
List<Notification> notifications,
String message) {
for (Notification n : notifications) {
      n.send(message); // polymorphic call
}
  }
}

Information Hiding

BankAccount — Hide Internals, Expose Contract

Private (Can Change): cachedTransactions, dbConnection, readBuffer, bufferSize — implementation details that must remain hidden.

Public (Stable Contract): addTransaction(), getBalance(), connectToDbAsync() — the interface the consumer depends on.

Use Understandable & Maintainable Code

❌ Hard to Understand

public int calc(int n) {
int s = 0;
for(int i = 0; i <= n; i++) {
if(i % 2 == 0) s += i;
  }
int f = 1, x = 5;
for(int i = 1; i <= x; ++i) { f *= i; }
return s;
}

✓ Separate methods with meaningful names

public int sumOfEvenNumbers(int limit) {
int sum = 0;
for(int i = 0; i <= limit; i++) {
if(isEven(i)) { sum += i; }
  }
return sum;
}
public int factorial(int number) {
int result = 1;
for(int i = 1; i <= number; i++) { result *= i; }
return result;
}

📋 Chapter 2 — Summary

Adaptability is achieved through deliberate design decisions — decoupling, hiding details, and isolating flexibility points
Determine where flexibility is needed: functionality, data, third-party, UI, platform
Strategy Pattern & Feature Flags — swap behaviors at runtime
Facade Pattern — decouple from complex third-party libraries
Configuration files for environment variability
Keep changes local — microservices, modular boundaries
Polymorphism for extensible behavior
Information Hiding — stable public contracts, hide internals
Understandable & maintainable code — readability enables change

Chapter Three · Quality Goals

Design Strategies for Achieving High Availability

High availability is achieved through three pillars: Error Prevention, Error Detection, and Error Handling — each playing a distinct role in keeping a system continuously operational.

🛡️

Error Prevention

Transactions, input validation & bottleneck elimination

🔍

Error Detection

Monitoring, metrics, alerts & result validation

🔄

Error Handling

Retry, fallback, rollback & redundant components

The Three Pillars of High Availability

1 — Error Prevention

Use Transactions
Input Validation
Eliminate performance bottlenecks

2 — Error Detection

Monitoring critical metrics
Validate accuracy of results across redundant components

3 — Error Handling

Robust exception handling
Rollback mechanisms
Redundant system components
Auto-replace defective components

Error Prevention — Using Transactions

❌ No Transaction — Partial Failure Risk

-- If the second UPDATE fails, CompanyX loses -- 1000 but Bob never receives it! UPDATE accounts SET balance = balance - 1000.00 WHERE name = 'CompanyX';
-- ← SYSTEM CRASH HERE ⚠ UPDATE accounts SET balance = balance + 1000.00 WHERE name = 'Bob';
-- ❌ CompanyX lost 1000, Bob never received it!

✓ With Transaction — Atomic, All-or-Nothing (BEGIN ... COMMIT)

BEGIN;
UPDATE accounts SET balance = balance - 1000.00 WHERE name = 'CompanyX';
UPDATE accounts SET balance = balance + 1000.00 WHERE name = 'Bob';
COMMIT; -- ✓ Only if BOTH succeed — atomic guarantee -- If anything fails between BEGIN and COMMIT, -- the entire transaction is rolled back automatically. -- Neither CompanyX nor Bob's balance is changed.

Error Prevention — Input Validation

Strictly Define Valid Input

Define what is valid input at every boundary
Define what is invalid and reject it early
Prevents both accidental errors and malicious attacks

Error Prevention — Performance Bottleneck Prevention

Identify & Eliminate Bottleneck Stages

Identify bottleneck stages in processing pipelines
A slow stage creates back pressure — upstream stages stall waiting for it to clear
Downstream stages starve — they have nothing to process
Throughput of the entire pipeline is limited by the slowest stage

⚠ Back Pressure — Color Correction bottleneck stalls the entire image pipeline

✓ Solution — Parallelize the bottleneck stage to match upstream throughput

Error Detection — Monitoring

Critical Metrics to Monitor

Uptime

HTTP req/sec

Error Rate

CPU / Memory

Error Status Codes

Latency P99

Disk I/O

Queue Depth

Critical metrics must be published and aggregated for both visual (dashboards) and programmatic (alerting) monitoring.

Error Detection — Validating Accuracy of Results

Cross-Validation for Data Consistency

Redundant data sources should produce consistent results when cross-checked
Compare the sum of all account balances against the sum of all wire transfers
If the net total doesn't match the expected value, data corruption or a bug has occurred
Run these checks periodically (scheduled jobs) or after critical operations

Example: A banking system has two tables — accounts (current balances) and wire_transfers (pending transfers). By summing both, the system verifies that money was neither created nor lost. If CompanyX has 10,000 and Bob has 50 in accounts, and there are pending transfers of −300 (CompanyY→CompanyZ) and +250 (Jane→Bob), the net total should be exactly 10,000. Any deviation signals a consistency error.

-- Cross-validate accounts table against wire transfers for consistency -- Expected: money is neither created nor lost SELECT
(SELECT SUM(balance) FROM accounts) +
  (SELECT SUM(amount) FROM wire_transfers)
AS net_total_balance;
-- accounts: --   CompanyX  = 10,000 --   Bob       =     50 --   Total     = 10,050 -- wire_transfers (pending): --   CompanyY → CompanyZ = -300 --   Jane     → Bob      = +250 --   Total               =  -50 -- net_total_balance = 10,050 + (-50) = 10,000  ✓ consistent -- If result ≠ 10,000 → ⚠ data corruption detected!

Error Handling — Robust Exception Mechanisms

Try-Catch — Catch & Handle Exceptions

Wrap risky operations in a try-catch block
Catch specific exceptions — don't swallow errors silently
Log the error, return a meaningful response to the caller
Prevents unhandled crashes from bringing down the service

Retry with Backoff

Server catches exception from External Broker Service
Waits and retries — transient failures often self-resolve
Use exponential backoff to avoid thundering herd
✓ Green path: retry succeeds

Fallback to Alternative

If primary broker fails, route to Another Broker Service
Circuit Breaker pattern prevents cascade failures
Consumer is unaware of the fallback — transparent recovery

Error Queue for Future Verification

Add failed trades to an error queue
Queue enables asynchronous retry and audit
Prevents data loss — no trade is silently dropped

Error Handling — Transaction Rollback

ROLLBACK — Undo Partial Work on Failure

Wrap related operations in a BEGIN ... COMMIT / ROLLBACK block
If a business rule fails mid-transaction, ROLLBACK undoes all preceding changes
Prevents selling out-of-stock items in a race condition
Atomicity guarantees data integrity — the database is never left in a half-done state

Example: An e-commerce system processes a purchase. It first inserts a sale record, then checks inventory. If inventory is zero, the ROLLBACK undoes the sale insert — the customer never gets charged for an out-of-stock item, and the database stays consistent.

✓ Transaction with conditional ROLLBACK

BEGIN;
-- Step 1: Optimistically insert the sale INSERT INTO sales (product_id, user_id)
VALUES (@product_id, @user_id);
-- Step 2: Lock the inventory row and check count SELECT count FROM inventory
WHERE product_id = @product_id
FOR UPDATE; -- row-level lock prevents race conditions IF count > 0 THEN -- ✓ In stock — decrement and commit UPDATE inventory SET count = count - 1 WHERE product_id = @product_id;
COMMIT; -- sale + inventory update both persist ELSE -- ✗ Out of stock — undo the INSERT, nothing changes ROLLBACK; -- sale record is removed, DB unchanged END IF;

Eliminating Single Points of Failure

Redundancy at Every Layer

Identify every component that, if it fails, brings the whole system down
Replace single nodes with clustered / replicated equivalents
Use active-active or active-passive failover depending on RTO/RPO requirements
Auto-replace defective components — health checks + orchestration (e.g., Kubernetes, ECS)
Release Version Rollback — ability to instantly roll back a bad deployment

⚠ Before — Single points of failure at every layer

✓ After — Redundancy at every layer eliminates single points of failure

📋 Chapter 3 — Summary

High availability demands a layered defense — prevent, detect, and handle errors gracefully
Transactions for atomic operations — all-or-nothing consistency
Input validation at every boundary — reject bad data early
Eliminate performance bottlenecks — prevent cascading failures
Monitoring — metrics, alerts, dashboards for real-time visibility
Validate accuracy across redundant components
Retry, fallback, error queues — graceful degradation
Rollback — transactions & release version rollback
No single point of failure — any node can fail without system outage

Summary — All Three Quality Goals at a Glance

01 · High Performance

Design Strategies for Performance

Perform load tests
Additional hardware & load balancing
Reduce / increase distribution (sharding)
Compromise on energy efficiency
Reduce communication (cache, batch)
Reduce flexibility of the system

02 · Adaptability & Flexibility

Design Strategies for Adaptability

Keep changes local
Use configuration files
Determine where flexibility is needed
Use understandable & maintainable code
Decouple system components
Use Information Hiding
Use polymorphism

03 · High Availability

Design Strategies for Availability

Error Prevention — transactions, validation
Error Detection — monitoring, result validation
Error Handling — retry, fallback, rollback
Eliminate single points of failure
Redundant system components
Auto-replace defective components