Modeling throughput for millions of transactions per second (TPS) is done using a combination of queueing theory, service-time decomposition, contention modeling, and system-level simulation. In enterprise platforms like IBM Z or large distributed systems, you don’t model TPS as a single number—you model it as a pipeline of constrained resources under load.

The core idea is:

Throughput is determined by the slowest saturated resource under concurrency, not by raw CPU capacity alone.

1. Core throughput definition

At a high level:

Throughput (TPS) = Completed Transactions / Time

But in real systems:

Throughput = function(CPU, memory, I/O, locks, cache, contention, latency)

2. Fundamental modeling approach

A. Queueing model (core of TPS modeling)

Most systems are modeled as:

Arrival rate (λ) → Queue → Service center → Departure rate (μ)

Using Little’s Law:

L = λ × W

Where:

• L = number of transactions in system
• λ = arrival rate (TPS)
• W = average response time

👉 This links throughput and latency directly.

3. Multi-layer service decomposition

A transaction is split into components:

Example breakdown:

• CPU execution time
• DB access time (lock + buffer)
• memory access time
• I/O wait time
• network / interconnect delay

So:

T_total = T_cpu + T_memory + T_io + T_lock + T_sync

👉 Throughput is limited by the dominant component under load.

4. Bottleneck identification (key concept)

Maximum TPS is determined by:

Throughput_max ≈ 1 / max(service_time per resource)

So if:

• CPU handles 200k TPS
• I/O handles 80k TPS
• lock manager handles 60k TPS

👉 System throughput = 60k TPS (bottleneck = lock contention)

5. Contention modeling (critical for millions TPS)

At high TPS, contention dominates:

A. Lock contention

• serialized access reduces parallelism

B. Cache contention

• cache line bouncing reduces efficiency

C. Memory bandwidth saturation

• limits concurrent data movement

D. I/O queue saturation

• device queue depth limits throughput

6. Closed vs open system models

A. Open system (request-driven)

• arrival rate is external
• throughput depends on system capacity

B. Closed system (fixed users/workers)

Used in mainframe modeling:

N users → think time → system → response → loop

👉 Throughput depends on:

• number of active sessions
• response time
• CPU saturation

7. Scalability modeling (key for millions TPS)

You analyze:

A. Linear scaling region

• throughput increases proportionally with resources

B. Saturation point

• bottleneck appears
• curve flattens

C. Degradation region

• contention causes throughput collapse

8. Multi-core / SMP modeling

For systems like IBM Z / POWER:

Throughput is modeled as:

TPS = min(CPU_parallel_capacity, memory_bandwidth, I/O bandwidth, lock throughput)

With adjustments for:

• SMT efficiency
• cache sharing efficiency
• interconnect latency

9. Transaction pipeline modeling (real enterprise view)

Each transaction goes through stages:

1. dispatch
2. CPU execution
3. memory fetch/store
4. I/O or DB access
5. commit/logging

Each stage has:

• service time
• queue depth
• contention factor

👉 Overall TPS = slowest effective pipeline stage

10. Simulation techniques used

A. Discrete-event simulation

• models each transaction event-by-event

B. Monte Carlo simulation

• randomizes arrival/service times
• estimates peak TPS behavior

C. Trace-driven modeling

• uses real workload logs

11. IBM-style workload modeling (important concept)

In IBM Z environments:

• Workload Manager (WLM) classifies transactions
• service classes define response goals
• system dynamically adjusts dispatching priority

👉 So throughput is not static—it is policy-driven

12. Scaling law intuition

At very high TPS:

Amdahl-like effect:

Speedup limited by serial fraction

Even with more CPUs:

• lock manager becomes bottleneck
• memory bandwidth saturates
• I/O queues fill

13. Simple mental model

Think of modeling millions TPS as:

A multi-stage pipeline where thousands of parallel execution lanes process transactions, but overall throughput is determined by the most congested shared resource—typically locks, memory bandwidth, or I/O paths—rather than raw CPU power.

14. Key takeaway

To model millions of TPS, you must:

• use queueing theory (Little’s Law)
• decompose transaction service times
• identify bottlenecks (CPU, memory, I/O, locks)
• model contention explicitly
• simulate scalability limits under load
• account for system policies (like WLM in IBM Z)

👉 Result: TPS is always bottleneck-driven, not CPU-driven