Steve's Number of Zeros for Integrations

Volume planning is crucial, and it’s the one question the business never wants to answer. How many accounts do you have? “Well, it’s going to grow.” So I start throwing numbers at them. Ten? A hundred? A thousand? Ten billion? I get a little ridiculous, and then they finally say, “Okay, a hundred thousand.”

You don’t need the exact number. You need the number of zeros. This page is the method, four worked examples, and a calculator you can use with the business in the room. The Integration Architect course teaches it in Steve’s Number of Zeros.

The Method

1. Get the business to agree to baseline numbers they clearly understand and will commit to.
2. If they can’t agree on an accurate number, pick one with just the number of zeros (10, 100, 1,000, … 1 million, 10 million), and aim slightly higher if they can’t commit.
3. Turn the numbers into the units an integration is designed for:
   • transactions per second (TPS): how many calls or messages;
   • records per second: a transaction can carry more than one record;
   • bytes per second: how much data actually moves;
   • the activity window: how many hours a day it really happens in.

The calculation always goes the same way. Start from the business’s own words, turn them into transactions, records and average size for one day, and then spread that day over the activity window:

Step	Transactions	Records	Bytes
One day	transactions a day	transactions × records per transaction	transactions × average bytes per transaction
One second	transactions a day ÷ seconds in the window	records a day ÷ seconds in the window	bytes a day ÷ seconds in the window

The seconds in the window are the hours × 60 × 60. An 8-hour day is 28,800 seconds; a 12-hour day is 43,200.

The Activity Window Is the Peak

Integrations don’t run evenly for 24 hours. They pulse, and they surge. You may have this much in a day, but you need to move it in two hours. So the per-second numbers are smoothed: the day spread evenly over the window. Shrink the window and the same day gets denser. Choose the window the business really works in, and plan for your highest season, not your average one.

Smoothed numbers are the start. Estimating the real peaks, and the queues and workers that absorb them, is the integration team’s next job.

The Worked Examples

Four examples, one method. The business never talks in transactions per second, and each example gets to “a day” a different way: the method bends to how the business talks. Each tab is laid out like the calculator below: what the business says, how it becomes one day, and the results.

Opportunities Trucks Appointments Cases

Opportunity close

Closed opportunities sent to the ERP, near real time.

What the business says

• 500,000 accounts
• Each closes about 8 opportunities a month
• Each opportunity has 10 line items
• About 50 KB per opportunity
• 22 working days a month
• A 12-hour working day

One day, worked out

• 500,000 × 8 = 4,000,000 transactions a month
• ÷ 22 working days = 181,818 transactions a day
• Records: the opportunity and its 10 lines, 11 each = 2,000,000 a day
• Data: 181,818 × 50 KB = 9.09 GB a day
• The window: 12 hours = 43,200 seconds

	Transactions	Records	Data
One day	181,818	2,000,000	9.09 GB
One second	4.21	46.3	210 KB

The business talked in months, so the first step is a day: divide by the working days. And look at records against transactions: 4.21 transactions a second, but 46.3 records. Anything that counts records, a limit, a log, storage, feels the 46.

Try it in the calculator

Truck deliveries

Delivery notifications from the trucks, as they happen.

What the business says

• 1,000 trucks
• 10 deliveries per truck a day
• 4 notifications per delivery: arrived, status update, job completed, departed
• 1 record per notification
• 3 photos per delivery, about 4 MB each
• A 12-hour working day

One day, worked out

• 1,000 × 10 × 4 = 40,000 transactions a day
• Records: 1 each = 40,000 a day
• Photos spread over the notifications: 3 ÷ 4 = 0.75 a message × 4 MB = a 3 MB average
• Data: 40,000 × 3 MB = 120 GB a day
• The window: 12 hours = 43,200 seconds

	Transactions	Records	Data
One day	40,000	40,000	120 GB
One second	0.926	0.926	2.78 MB

Under one transaction a second, but 120 GB a day: count transactions and bytes separately. And the average hides the largest message: the photos ride on the "job completed" message, 3 × 4 MB = 12 MB in one. The average sizes the day; the largest message sizes the mechanism.

Try it in the calculator

Appointment messages

Text and email reminders to customers with appointments.

What the business says

• 1,000 stores
• 100 appointments per store a day
• 3 messages per appointment: the day before, the day of, on arrival
• 5 items per appointment
• About 10 KB per message
• Stores in two time zones

One day, worked out

• 100 × 1,000 × 3 = 300,000 transactions a day
• Records: the appointment and its 5 items, 6 each = 1,800,000 a day
• Data: 300,000 × 10 KB = 3 GB a day
• The window: 8 hours in the first time zone, plus 3 for the last one = 11 hours = 39,600 seconds

	Transactions	Records	Data
One day	300,000	1,800,000	3 GB
One second	7.58	45.5	75.8 KB

Almost eight transactions a second, but little data: the opposite of the trucks. And the window comes from the time zones: the day doesn't end until the last store closes.

Try it in the calculator

Case updates

Every case change sent to a second system, near real time.

What the business says

• 500 agents
• One case created or updated every 5 minutes: 12 an hour
• 8 hours a day, one time zone
• 2.5 records per update: the case, plus comments and activity
• About 10 KB per update

One day, worked out

• 500 × 12 × 8 = 48,000 transactions a day
• Records: 2.5 each = 120,000 a day
• Data: 48,000 × 10 KB = 480 MB a day
• The window: the working day, 8 hours = 28,800 seconds

	Transactions	Records	Data
One day	48,000	120,000	480 MB
One second	1.67	4.17	16.7 KB

Nobody can tell you what a person does, so you act it out: open a case, type, type, type, hit save. Five minutes. Even 500 people typing away make real traffic.

Try it in the calculator

The Calculator

Type the business’s numbers, or just their number of zeros. Everything recalculates as you type. Start from one of the examples, or from a blank. Nothing you type leaves your browser.

For teaching only: this calculator gives estimates from the numbers you type, smoothed over the activity window. It isn’t a sizing, a quote or a guarantee. Before you make a decision, confirm the volumes, the limits and the costs with your own data, your integration team and current Salesforce documentation.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

Change one number at a time and watch which result moves.

The question

Name of this flow What the business said: its numbers, in its own words, one to a line

One day

Records per transaction

The activity window

Hours of activity a day

Growth (optional)

Growth a year, % Years ahead

	Transactions	Records	Data
One day
One second
One second, in 3 years

Smoothed over the activity window. KB = 1,000 bytes, MB = 1,000,000, GB = 1,000,000,000. Estimates for teaching, not a sizing or a guarantee.

Download the question and the answers (CSV)

Do Your Math Early

Calculate the integration traffic early. It decides how big the integration layer has to be, which mechanisms will fit, and which limits you’ll meet. Do it with the business in the room, one number at a time, and write down what they agreed to. And then do it again for three years out: at 30% a year, that’s about 2.2 times today.