화살표 이전에

19개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

An old hand pump over a well, water pouring from the spout into a bucket. — AI로 생성한 이미지

Data Architect 과정 9장인 통합과 데이터 이동의 모듈 1/4. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 지난 장, 쿼리와 조회 아키텍처 · 다음: 키와 쓰기 소유권

The question this module answers: What must a data architect know about an integration before anyone draws the arrow? ⟲

Start With the Picture

Here’s Steve Trucking at the end of Part 1. At Checkpoint 1 I drew what I would architect: the partners’ manifests coming in, status going back out, the latest truck position from FleetLink, status events to Snowflake, delivery counts to the finance ERP. And in the middle of all those arrows, I drew a box and wrote on it: Integration, designed in Part 2. ⟲

This is Part 2. ⟲

클릭하여 확대

Checkpoint 1’s landscape. Every arrow on it is a decision about data; this module zooms in on one. ⟲

I love system landscapes. Even two boxes protect you: put one up on a first call and you’d be surprised how many memories are suddenly jogged. “Wait, where’s my mobile app? Where’s the push of my orders?” But a landscape has a weakness, and it’s the arrows. Look at this one. Every arrow is the same thin line. One of them might carry one record every few minutes, another 500 a minute, another a nightly file of 200,000. One is a request where Salesforce waits for an answer; another is an event Salesforce publishes and forgets. Those aren’t the same architecture. The picture doesn’t show the difference. So before I draw an arrow, I want to know what it means. ⟲

That’s what before the arrow means: the data questions you answer before anyone chooses REST, events, files or middleware. ⟲

“그건 통합 아키텍트가 처리하고 있어요”

Maybe. On a large program, someone else may design the APIs, events, transformations and middleware. That’s fine. This chapter is a sampler plate; the Integration Architect course is the full meal. But I absolutely want to know what the integration architect is planning, because the integration is about to touch my data. An API pushing hundreds of records a minute is a different data problem from an hourly bulk load. Those writes can fire automation, recalculate sharing, lock parent records, run duplicate checks and validation, update roll-ups, grow storage and trigger other integrations. The data architect doesn’t have to build the integration, but decides what it’s allowed to do to the data. Understand the traffic that’s coming. ⟲

Zoom In on One Arrow

So let’s pick one arrow and look closely: Redrock’s manifests, coming in through the integration layer and landing in Salesforce. In chapter 4 we zoomed in on an arrow too, and saw the plumbing: where the server listens, how the client authenticates, the protocol and the payload. That’s the integration architect’s view. Here’s the data architect’s view of the same kind of arrow: seven questions, and what each answer does to the data. ⟲

클릭하여 확대

One arrow, seven questions. None of the answers names a technology. ⟲

Read down the left column. Redrock starts it. The manifests move from Redrock to Salesforce. They’re sent a day or two ahead, but revised on the day. About 1,100 deliveries a day arrive as a set per distribution center each evening, then as single revisions. Redrock’s order and delivery reference identifies each one. Redrock owns what was ordered and where it goes. And Redrock, as the client, is the one that sees whether the call worked. ⟲

Now the right column, which is where the data architect lives. A resent manifest must update, not duplicate. Redrock may change the items and the address, but not the crew. A coordinator must see a revision before the truck leaves the dock. About 350,000 Work Orders a year come down this one arrow, growing 30% a year. Notice what isn’t in either column: REST, Bulk API, platform events, MuleSoft. Choose the mechanism before you understand the movement, and you’re designing backwards. ⟲

The seven questions, for every important arrow: ⟲

Who starts it? ⟲
Which way does the data move? ⟲
얼마나 최신이어야 하나요?
데이터가 얼마나 많고, 어떤 모양인가요?
What’s the key? ⟲
누가 어떤 필드를 쓸 수 있나요?
성공했는지 누가 알고, 실패하면 누가 복구하나요?

This module works through the first four, plus what an arrow costs. Module 2 takes the key and the write authority; module 3 takes the last question. ⟲

누가 시작하는지와 데이터 방향은 다릅니다

What does an arrow on a landscape mean? Ask a room and you get two answers. One: who’s the client and who’s the server, who opens the connection. Two: which way the data flows. Both are fair, and they can point in completely opposite directions. A user connects to Salesforce and a sea of data flows back the other way. So you have to decide what your arrows mean. I draw mine from the system that opens the connection, and I put what moves, and which way, in the label. That’s the rule on every landscape in this course. ⟲

Take FleetLink. At Checkpoint 1 we decided Salesforce keeps only each truck’s latest position. That data moves one way: FleetLink to Salesforce. But who starts it? Two designs: ⟲

Salesforce asks. Every few minutes a scheduled job in Salesforce calls FleetLink: “Where are my trucks?” Salesforce is the client. The data still flows FleetLink → Salesforce. ⟲
FleetLink tells. Whenever a truck moves far enough, FleetLink calls into Salesforce with the new position. FleetLink is the client. The data still flows FleetLink → Salesforce. ⟲

Same data, same direction, different initiator. And it matters, because the initiator carries the load and the responsibility. In the first design, Salesforce spends its own limits making calls, holds FleetLink’s credentials, and has to handle FleetLink being down. In the second, FleetLink spends Salesforce’s API calls, and FleetLink has to notice when Salesforce rejects something. In class I call this the direction of action: who’s starting the action, which can be different from the data flow. ⟲

클릭하여 확대

Salesforce asks. Salesforce starts it; the positions flow FleetLink → Salesforce. ⟲

클릭하여 확대

FleetLink tells. FleetLink starts it; the positions still flow FleetLink → Salesforce. ⟲

At its simplest, it’s still client and server. The client starts the conversation and the server listens. The server knows whether it received, rejected, processed or failed the request. What it can’t see is whether its response made it back. The client can. Only the client sees the whole round trip. That has a big consequence for recovery, which module 3 makes concrete. ⟲

Test knowledge. Separate who initiates an integration from which way the data flows. “Salesforce calls the ERP to get the credit status” is Salesforce-initiated, but the data flows from the ERP into Salesforce. Expect scenarios that describe one and ask about the other. ⟲

얼마나 최신이어야 하나요?

The first word I challenge is “real time.” Why? What happens if it’s five seconds old? Thirty seconds, five minutes, an hour, tomorrow morning? There are real real-time requirements, and plenty labeled real time because nobody asked the next question. ⟲

I teach three timings: ⟲

Real time is synchronous: the caller waits for the answer. A user can’t take the next step until it comes back. It’s the hardest to build and has the most error handling. ⟲
Near real time is anywhere from under a second to a minute, two, maybe five. There’s a big difference between sub-second and one to five minutes, and near real time is a lot cheaper and easier to maintain than real time. ⟲
Batch is hourly, daily or weekly. Old school, and often exactly right. ⟲

Now put Steve Trucking’s arrows on that ladder. ⟲

The arrow	How current it needs to be	Timing
Status out to Redrock, by webhook	As it happens: Redrock shows it to its own customers	Near real time, seconds
Latest truck position, FleetLink → Salesforce	A few minutes old is fine for “your truck is about 20 minutes away”	Near real time, minutes
Redrock’s manifest revisions	Before the truck leaves the dock	Near real time, minutes
Status events, Salesforce → Snowflake, through the integration layer	Today’s dashboards; nobody runs the company from the last second	Near real time or hourly batch
Status file to Keystone	Keystone asked for it each night	Batch, daily
Delivery counts to the finance ERP	Partners are invoiced monthly	Batch, daily is plenty

Look at what’s missing: nothing on this landscape needs Salesforce to wait for another system’s answer. That’s not unusual. Real time costs more calls, more events, more processing, more contention and more operational complexity, so I want a reason for every one. If a nightly update meets the need, I’m not embarrassed to use one. Freshness is a requirement, not a default. ⟲

Salesforce’s Well-Architected framework makes the same point from the other side: the mechanism you pick sets how much you can lose and how stale a copy can get. Its Reliability (새 탭에서 열림) guidance lists replication choices by that measure. Change Data Capture provides “near real-time replication with minimal development effort.” Platform events carry your own payloads, but need publish logic you build. A scheduled Bulk API 2.0 extraction is the simplest, “with an RPO equal to extraction frequency”: a nightly extract can be a day stale, by design. ⟲

Test knowledge. Match the timing to the mechanism. Waiting for an answer (request and reply) needs a synchronous call. Fire and forget from Salesforce: platform events (outbound messages are the older option). Keeping another system in step with Salesforce changes: Change Data Capture. Large scheduled loads: the Bulk API. Watch for scenarios that say “immediately” when the business only needs minutes. ⟲

Asking Every Minute

There’s a way to get near real time that looks simple: ask. A process outside Salesforce calls in on a schedule. “Has anything changed? Has anything changed? Has anything changed?” That’s polling. Once a minute doesn’t sound horrendous, until you do the math: 60 times 24 is 1,440 calls a day, for one question, from one system. Every call uses an API request from your allocation and puts its own load on Salesforce, whether or not anything changed. ⟲

Say the finance ERP wants Steve Trucking’s delivery counts, and someone builds a job that asks Salesforce every five minutes. That’s 288 calls a day and over 105,000 a year, for numbers the business invoices once a month. Almost every one of those calls comes back with nothing that matters. Well-Architected’s Resource and Cost Optimization (새 탭에서 열림) pillar has a name for that: an integration that polls every five minutes and finds nothing “is pure waste.” A nightly batch serves finance better, at a fraction of the calls. ⟲

Now take Snowflake, which wants every status change, and soon. First question: who asks? Not Snowflake. A database stores; a process calls. Tables don’t start conversations. Something has to wake up, make the call, handle the error, retry and write the result. Salesforce can be that process for its own outbound calls, but Salesforce doesn’t poll itself on another system’s behalf. So when neither end runs the process you need, you add a third piece of software: middleware, the integration layer. ⟲

Look closely and even the “built-in” options are that third piece. Snowflake’s own Salesforce connector runs on Snowflake Openflow, which Snowflake describes as “an integration service” built on Apache NiFi; it polls Salesforce’s Bulk API 2.0 on a schedule, from every minute to once a day (Openflow (새 탭에서 열림) and its Salesforce Bulk API connector (새 탭에서 열림), checked 2026-10-27). Or you write a stored procedure that calls out through Snowflake’s external network access (새 탭에서 열림) and schedule it as a task. Either way it’s a process, with its own credentials, schedule and failures, and someone has to own it. (When that connector’s page says it “supports Change Data Capture,” it means its own change detection by timestamp, not Salesforce’s change events.) Can it be done? Yes. Would I, and should I? That’s the architecture decision, not a feature of the database. ⟲

So the integration layer can poll: every minute, “anything changed?”, 1,440 calls a day, most finding nothing. Or Salesforce can tell it. I could build the telling myself: a record-triggered flow on the Work Order, query the fields, put them on a platform event, and the integration layer subscribes and writes them to Snowflake. It works. Then someone adds a field to the Work Order. Now I have to add it to the flow’s query, add it to the platform event, and change the subscriber and Snowflake’s table too. That’s code to maintain, forever, keeping up with the object’s definition. ⟲

Or I turn on Change Data Capture for the Work Order. No flow and no event to maintain: Salesforce publishes a change event for every create, update, delete and undelete, with the changed fields, and a new field is picked up automatically. Work Order and Service Appointment both support it, checked against the Object Reference (새 탭에서 열림), Winter ‘27. ⟲

But count the zeros first. About 3,300 deliveries a day, with about 8 status changes each, is roughly 26,400 status changes a day, before any other field on the Work Order changes. CDC sends every change, not just status. And event delivery has a daily allocation: without an add-on, 50,000 delivered events in a rolling 24 hours for Performance and Unlimited Editions and 25,000 for Enterprise Edition, shared with high-volume platform events and counted per subscriber, so two subscribers use it twice (Change Data Capture Allocations (새 탭에서 열림), checked 2026-10-27). When I first taught this, the warning was “you’re going to get a tsunami of data.” Today you can filter the stream (새 탭에서 열림) in a custom channel, so the subscriber receives only the status changes it asked for. And the subscriber is middleware too: receiving change events means holding a subscription open to Salesforce’s Pub/Sub API, a job for an integration layer such as MuleSoft or a Kafka connector, not for the warehouse. Event-driven is better than polling for this arrow, but it still has a number of zeros. ⟲

클릭하여 확대

The integration layer asks on a clock: 1,440 calls a day, most of them finding nothing. ⟲

클릭하여 확대

The integration layer listens instead. Snowflake receives either way: a database stores; a process calls. ⟲

Salesforce’s own Best Practices for Deployments with Large Data Volumes (새 탭에서 열림) gives an older form of the same advice for keeping another system in step with Salesforce. Use the SOAP API’s getUpdated() and getDeleted() calls “to sync an external system with Salesforce at intervals greater than 5 minutes,” and “use the outbound messaging feature for more frequent syncing” (Extracting Data from the API (새 탭에서 열림), Winter ‘27, checked 2026-10-27). The idea still holds. On a schedule, ask only for what changed, and don’t forget what was deleted. When it has to be sooner than that, let Salesforce tell you. The mechanism has moved on: outbound messaging gets no further investment (module 3), so today the telling is usually Change Data Capture or platform events. ⟲

Test knowledge. Pulling changes out of Salesforce on a schedule: getUpdated() and getDeleted() return what changed and what was deleted in a time window, for intervals over 5 minutes. More often than that, let Salesforce send the change (Salesforce’s guide names outbound messaging; today, Change Data Capture or platform events). Expect a scenario where a full extract every few minutes is the wrong answer. ⟲

0의 개수는 통합에도 적용됩니다

Then: how much? Not “is it a lot?” Give me the zeros. And not just the daily number; tell me how it arrives. An integration team wants three numbers: transactions per second, bytes per second, and the activity window, the hours the traffic actually runs. You may have 24 hours in a day, but the data doesn’t arrive at 2 a.m. Steve Trucking’s crews work about twelve hours, so that’s the window. ⟲

Steve Trucking’s traffic	A day	Per second, in a 12-hour window	Bytes
Truck positions from FleetLink	about 200,000 readings	about 4.6	tiny: a position and a time
Delivery status changes	about 26,400	about 0.6	small
Delivery photos	about 13,200 photos	about 0.3	heavy: at about 4 MB each, 53 GB a day, 1.2 MB every second

Look at the photos: under one transaction every three seconds, and still the heaviest arrow on the landscape. Positions are the opposite: the most transactions, almost no bytes. A lot of data with low transactions per second, or high transactions per second with little data: they have completely different behavioral profiles. Count both. And plan for the busiest season, not the average day. ⟲

I also think of integration traffic in three shapes: ⟲

Singles. One record at a time: a status change, an order. Exactly right for transactional activity. But send 100,000 records one at a time as fast as you can, and a reasonable pattern becomes a machine gun: every call has overhead, may run automation and competes for resources. ⟲
Sets. Bundle them, tens or hundreds per call, and let the receiver process sensible groups. Redrock’s evening manifest is a set. For many integrations, the middle ground is the best fit. ⟲
Bulk. Hundreds of thousands or millions of records, like a historical load. Don’t pretend two million records are two million little real-time transactions. Salesforce has the Bulk API for bulk work: in class I call it the 18-wheeler next to the bank teller. ⟲

It’s a teaching model, not a limits table, but it makes you respect the zeros. ⟲

Salesforce’s guide does draw one line in numbers: “Any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0”; fewer than that should be “bulkified” synchronous calls, in REST (Composite, for example) or SOAP. And when you update, “send only fields that have changed” (Loading Data from the API (새 탭에서 열림), checked 2026-10-27). Sending every field every time is the integration version of the machine gun. Chapter 10 has the rest of that guide’s loading advice. ⟲

클릭하여 확대

Singles, sets and bulk. A teaching model, not platform limits. ⟲

Test knowledge. For hundreds of thousands or millions of records, the answer is the Bulk API, not many single REST calls. Salesforce’s line: more than 2,000 records is a good candidate for Bulk API 2.0; fewer, bulkified synchronous calls. When API limits bite on a set of related records of different objects, look at the composite resources, which carry several operations in one call. When updating, send only the fields that changed. ⟲

통합 볼륨이 데이터 볼륨이 됩니다

외부 시스템이 분당 레코드 500개를 만든다고 합시다. 계속 돌아간다면 시간당 3만 개, 하루 72만 개, 1년이면 수억 건의 작업입니다. 계속 돌지 않을 수도 있고, 대부분이 갱신일 수도 있습니다. 좋습니다, 그래서 숫자가 필요합니다. 그때부터 데이터 질문이 시작되니까요. 어느 객체를 건드리나요? 소유권은 어떻게 분포하나요? 부모를 공유하나요? 어떤 자동화가 실행되고, 어떤 공유가 재계산되고, 이력 레코드가 생기나요, 롤업이 있나요, 보존 기간은요? 핫스팟을 만들 수 있나요? 이 레코드가 하나하나 전부 Salesforce에 필요한가요?

An integration can create a large-data-volume problem on its own. “Every time FleetLink sends a GPS position, we’ll create a Salesforce record.” That’s 200,000 a day: 73 million records a year. Before I care whether that’s REST, events or middleware, I ask: why would we put 73 million GPS readings a year into the transactional data model? At Checkpoint 1 we decided not to; only the latest position matters to the org. The integration mechanism doesn’t answer that question. It’s a data architecture decision. Sometimes understanding the integration redesigns the model; sometimes it redesigns the integration; sometimes it decides not to move the data at all. ⟲

데이터 이동은 공짜가 아닙니다

모든 사본에는 결과가 따릅니다. 저장 공간, 최신성, 동기화, 보안, 개인정보, 마스터 관리, 삭제, 대사. ERP의 고객 데이터를 Salesforce로 복사하면 관리해야 할 표현이 하나 더 생깁니다. 누가 소유하나요? 얼마나 오래되어도 되나요? 누가 Salesforce에서 바꾸거나, ERP가 5분 뒤 다른 값을 보내거나, 고객이 잊힐 권리를 요구하거나, 에이전트가 갱신하면 어떻게 되나요? 화살표는 바이트만 나르지 않습니다. 기업 데이터를 관리해야 할 곳을 하나 더 만듭니다.

Two of the seven questions get the next module. What’s the key? If Redrock resends delivery 8472914, does Salesforce create, update, reject or link? Without a stable key, retries become duplicates and reconciliation becomes guesswork; that’s why Checkpoint 1 gave every Work Order a key that matches the partner’s order. Who may write? If the finance ERP owns billing terms and Salesforce owns the appointment and the crew, an integration doesn’t mean “the ERP may update the record.” It means “the ERP may update these fields.” That’s chapter 6’s authority map made executable. A system-of-record diagram that doesn’t change write behavior is decoration. ⟲

그리고 실패할 때

It will. Here’s our landscape again, the same places, with the arrow we zoomed in on. Tonight’s Redrock manifest, 370 deliveries, reaches the integration layer, and the call into Salesforce times out. ⟲

클릭하여 확대

The arrow fails, on the whole landscape. ⟲

Now zoom in on that one arrow. Leave everything else behind: Salesforce on the left, the integration layer on the right, and the call between them. ⟲

클릭하여 확대

One arrow, one timeout. ⟲

Before you read on, stop and answer it. Did the manifest save? There are three honest answers. All of it: Salesforce saved all 370 Work Orders, and only the reply was lost on the way back. None of it: the call never finished. Some of it: 367 saved and 3 were rejected by a validation rule, and nobody has read the errors yet. Salesforce knows which one happened. The integration layer, the client, only knows it didn’t get an answer. ⟲

클릭하여 확대

Salesforce knows what it saved. The integration layer only knows it heard nothing back. ⟲

Now the integration layer does what clients do: it sends the manifest again. If every Work Order is matched by Redrock’s order and delivery reference, the resend updates what’s there and creates only what’s missing. If it isn’t, and the first call had saved, Steve Trucking now has 740 Work Orders for 370 deliveries, and two crews may be sent to the same door. Same timeout, very different data. That’s why the key comes before the mechanism (module 2), and why somebody has to own knowing whether it all arrived (module 3). ⟲

클릭하여 확대

The resend. Safe with a key; duplicates without one. ⟲

A timeout is only one of the common failures. A malformed payload, an expired token, a validation rule rejecting a record, a server down, record 7,428 of 20,000 failing, an event delivered twice. Here integration and data architecture become inseparable. The integration architect thinks about retries, queues, replay, error handling and monitoring. The data architect thinks about duplicates, missing records, partial state, stale values, broken relationships and the wrong system writing. Two views of the same failure. ⟲

So for every arrow I ask the same things. On every outbound arrow: where do I log, what do I tell the user, and how do I retry? On every inbound arrow: how do they recover? Errors will happen. ⟲

그리고 “API가 200을 돌려줬어요”는 데이터 품질이 아닙니다. 인터페이스는 작동했습니다. 의도한 레코드 10,000개가 모두 도착했나요, 아니면 9,997개인가요? 세 개가 거부되었나요? 재시도가 무언가를 중복시켰나요? 맞는 레코드가 바뀌었나요? 변환이 값을 망가뜨렸나요? 우리가 소유하지 않은 필드를 덮어썼나요? 그래서 제가 반복하는 규칙이 여기 딱 맞습니다. 신뢰하되 검증하라. 모듈 3이 그것을 구체적으로 만듭니다.

Beyond the exam: what AI changes. An agent looking up a delivery in another system is an integration. An agent updating Salesforce through an API, or calling Salesforce’s hosted MCP servers, is an integration; an agent retrying after a failure is an integration retry. The caller is new; the questions aren’t. Who starts it? The agent, on behalf of a user, with that user’s permissions. How much? An agent can ask the same question many times a day, so the number of zeros grows with every conversation (chapter 16’s tireless assistant (coming soon)). Treat every agent read and write path as an arrow, with identity, authority, volume, failure handling and observability. ⟲

아키텍트가 여기서 결정하는 것

What every important arrow means: who starts it, which way the data moves, how current it must be, and its volume and shape. ⟲
Whether “real time” is a requirement or a habit, and which timing each arrow really needs. ⟲
Which process runs each arrow (Salesforce, the other system, or middleware), whether it polls or listens for change, and what its events cost in allocations. ⟲
통합이 자동화, 잠금, 공유, 저장 공간, 볼륨 증가를 통해 데이터 모델에 압력을 주는지.
데이터가 애초에 Salesforce로 들어와야 하는지.
메커니즘을 고르기 전에, 통합에 어떤 안정적인 키와 쓰기 권한이 필요한지.
누가 상호 작용을 충분히 보고 성공을 검증하며 복구를 책임지는지.

Diagrams make systems look clean. Real integrations are conversations between systems that move data under rules and fail in specific ways. You don’t have to build each one, but once the arrow starts moving data, the integration design becomes part of your data architecture. So before REST, Bulk API, events or middleware, zoom in on the arrow and know what it means. Then design it. ⟲

더 알아보기

On this site: Steve’s Number of Zeros for Integrations, the method from this module with four worked examples and a calculator to use with the business in the room. ⟲
Salesforce, Best Practices for Deployments with Large Data Volumes (새 탭에서 열림), Winter ‘27 (last updated September 18, 2026): Loading Data from the API (새 탭에서 열림) and Extracting Data from the API (새 탭에서 열림), checked 2026-11-01. ⟲
Salesforce Architects, Data Integration with Salesforce (새 탭에서 열림) (decision guide), checked 2026-11-01. ⟲
Salesforce Architects, Well-Architected, Reliability (새 탭에서 열림) and Resource and Cost Optimization (새 탭에서 열림), checked 2026-11-01. ⟲
Snowflake, Openflow (새 탭에서 열림), checked 2026-11-01. ⟲
Salesforce Developers, Change Data Capture Allocations (새 탭에서 열림) (Change Data Capture Developer Guide), checked 2026-11-01. ⟲
Integration Architect 과정: 호출은 어떻게 작동하는가, 타이밍과 물량 (coming soon).
Snowflake, About the Openflow Connector for Salesforce Bulk API (새 탭에서 열림), checked 2026-11-01. ⟲
Snowflake, External network access overview (새 탭에서 열림), checked 2026-11-01. ⟲
Salesforce Developers, Object Reference: StandardObjectNameChangeEvent (새 탭에서 열림), Winter ‘27, checked 2026-11-01. ⟲
Salesforce Developers, Change Data Capture Developer Guide: Add a Filter with Tooling API (새 탭에서 열림), checked 2026-11-01. ⟲