Saiba o que a seta significa

🌐 Também em 19 idiomas

English · Español · 日本語 · 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)

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês Esta seção mudou em inglês e ainda não foi traduzida de novo. (28)

Capítulo 9 de Data Architect, Parte 2: Arquitetando em escala. Anterior: Arquitetura de consulta e recuperação.

A maioria dos problemas de qualidade de dados numa org conectada chega por uma integração. Duplicatas por causa de uma chave que falta. Valores desatualizados por causa de um lote que parou de rodar sem ninguém perceber. Campos sobrescritos por um sistema que nunca deveria escrevê-los. O arquiteto de dados não precisa construir a integração. Mas o arquiteto de dados decide o que ela pode fazer com os dados.

Image generated with AI. ⟲

Então este capítulo é um prato de degustação: uma provinha de integração para o arquiteto de dados, com a refeição completa no curso Integration Architect. Ele começa onde o capítulo 4 parou: toda seta do panorama precisa de um mecanismo. Agora toda seta precisa de um significado.

As ideias deste capítulo

• Zoom out, then zoom in. Start with the whole landscape, then take one arrow at a time and ask what it means to the data. ⟲
• Saiba o que o arquiteto de integração está planejando, mesmo quando outra pessoa constrói. A forma do tráfego muda o design dos dados.
• Quem começa a conversa não é para onde os dados fluem, e só o cliente vê a ida e volta inteira.
• Freshness is a requirement, not a default. And a database stores; a process calls: polling needs a process, and polling for nothing is waste. ⟲
• Singles, sets or bulk: respect the zeros. Integration volume becomes data volume. ⟲
• One key per record, one-to-one, in an External ID field marked unique. When one customer has several external records, add records, not fields: a hierarchy, peers or a child object (chapter 6), never a key field per system. ⟲
• A key isn’t authority. Integrations write the fields their system owns, not “the Account.” Two-way movement still has one owner per field. ⟲
• Proof of delivery: the client owns the conversation; whoever knows what should arrive proves that it did. Log every call, restart gracefully, retry safely, and send increments, not the universe. ⟲
• Os eventos de plataforma são a espinha dorsal; as mensagens de saída são legado, ainda suportadas, mas não onde os novos designs começam.
• Every important arrow gets a contract, written before the mechanism is chosen, and it outlives the technology. ⟲

O contrato de dados da integração

Every important arrow gets one, eleven lines: ⟲

Line	The decision
Iniciador	Quem começa a conversa?
Direção dos dados	Para onde os dados de negócio se movem?
Freshness	How current must the data be, in a number?
Volume and shape	How much, and as singles, sets or bulk?
Key	How do we identify the same record across systems?
Write authority	Which system owns, and may write, which fields?
Pattern	Request and reply, fire and forget, batch, or events?
Mecanismo	O que implementa?
Proof of delivery	Who proves it arrived, and owns recovery?
Sensitivity and travel	How sensitive is the data, and where does it pass through?
Change	How does the contract change without breaking the other side?

O caminho por este capítulo

Quatro módulos, cada um se sustenta sozinho.

1. Before the Arrow. Steve Trucking’s landscape, then one arrow: who starts it and which way the data moves, how current, polling or listening, singles, sets and bulk, and what happens when it fails. ⟲
2. Keys and Write Ownership. One key per record, upsert and safe retries, add records not fields, field-level authority, and loops. ⟲
3. Proof of Delivery. Who proves it arrived, the integration log, restarts and retries, the return receipt, the four shapes and monitoring. ⟲
4. The Integration Data Contract. Nine contracts on the landscape, one line by line; requirement, then pattern, then mechanism; the standard API or your own; where the data travels; and when the contract says don’t move it. ⟲

Not moving data at all (Salesforce Connect, mashups, zero copy) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). ⟲

O que um arquiteto decide aqui

• What each arrow means: initiator, direction, freshness, volume. ⟲
• Como os registros continuam correspondendo entre os sistemas, e quem pode mudar quais campos.
• Quem prova a completude e é responsável pela recuperação de cada movimentação.
• Se os dados deveriam se mover, afinal.

Além do exame: todo caminho de leitura e escrita de um agente é uma seta de integração. Um agente que “atualiza o cliente” precisa de uma chave, de um contrato de escrita estreito, de novas tentativas seguras e de observabilidade, porque quem chama, de forma probabilística, está invocando operações corporativas determinísticas. Cada módulo termina com o que a IA muda.

Para saber mais

• Salesforce Architects, Data Integration with Salesforce (abre em uma nova aba) (decision guide), checked 2026-11-01. ⟲
• Salesforce Architects, Integration Patterns (abre em uma nova aba), checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes (abre em uma nova aba), Winter ‘27, checked 2026-11-01. ⟲

Próximo: Migração e sincronização