Integration Trade-offs
Every integration decision involves trade-offs. The CTA review board does not want the “right” answer — they want to see that you understand the trade-offs and can justify your choice for the specific scenario. This page catalogs the most common integration trade-offs with guidance on when each side wins.
The magic phrase at the board
“The trade-off is…” followed by a clear statement of what you gain and what you sacrifice. Judges reward candidates who proactively acknowledge trade-offs rather than waiting to be challenged.
1. Synchronous vs Asynchronous
The most fundamental integration trade-off. Nearly every CTA scenario requires this decision for at least one integration touchpoint.
flowchart TD
A[Integration Requirement] --> B{User waiting<br/>for response?}
B -->|Yes| C{Response time<br/>< 2 seconds?}
B -->|No| F[Async]
C -->|Yes| D{Low volume?}
C -->|No| F
D -->|Yes| E[Sync]
D -->|No| F
F --> G{Multiple subscribers?}
G -->|Yes| H[Platform Events / CDC]
G -->|No| I{Large volume?}
I -->|Yes| J[Batch / Bulk API]
I -->|No| K[Queueable / Future]
| Dimension | Synchronous | Asynchronous |
|---|---|---|
| User experience | Immediate feedback | Delayed confirmation |
| Coupling | Tight — caller depends on callee availability | Loose — systems operate independently |
| Consistency | Immediate — data is consistent right away | Eventual — temporary inconsistency |
| Error handling | Simple — caller gets the error directly | Complex — needs monitoring, DLQ, replay |
| Scalability | Limited by slowest participant | Each system scales independently |
| Governor limits | 10s callout timeout, 120s total | No callout pressure (async processing) |
| Complexity | Lower (simple request/response) | Higher (event handling, replay, idempotency) |
When Sync Wins
- User is staring at a screen waiting for validation results
- The downstream response is required to complete the business transaction
- Volume is low and the external system responds in under 2 seconds
- Strong consistency is a hard business requirement
When Async Wins
- The process can continue without waiting for the external response
- Volume is too high for synchronous processing
- The external system has unpredictable latency or availability
- Multiple downstream systems need the same event (fan-out)
The default should be async
Unless you have a specific reason for synchronous, default to asynchronous. It is more resilient, more scalable, and handles failure more gracefully. The burden of proof is on synchronous — justify WHY the user must wait.
2. Middleware vs Direct Integration
flowchart TD
A[How many integrations?] --> B{"< 4 systems?"}
B -->|Yes| C{Simple CRUD<br/>no transforms?}
C -->|Yes| D[Direct Point-to-Point]
C -->|No| E{Team has<br/>middleware skills?}
B -->|No| E
E -->|Yes| F{Budget allows<br/>middleware license?}
E -->|No| D
F -->|Yes| G[Middleware / iPaaS]
F -->|No| H[Custom integration layer]
D --> I["ROI: Lower cost, higher maintenance"]
G --> J["ROI: Higher cost, lower per-integration cost"]
When to invest in middleware infrastructure versus keeping things simple.
| Dimension | Direct (Point-to-Point) | Middleware |
|---|---|---|
| Cost | Low upfront, linear maintenance growth | High upfront, decreasing per-integration cost |
| Time to deliver | Fast for first integration | Slower to set up, faster for subsequent |
| Monitoring | Per-integration, fragmented | Centralized, comprehensive |
| Transformation | In Salesforce Apex or external code | Dedicated transformation engine |
| Governance | Minimal, per-team | Centralized API management |
| Team skills | Salesforce developer can build | Requires middleware expertise |
| Maintenance | Each integration maintained independently | Shared infrastructure, reusable patterns |
| Vendor lock-in | None | Tied to middleware vendor |
When Direct Wins
- 2-3 simple integrations that are unlikely to grow
- Team lacks middleware expertise and timeline is tight
- Integration is simple CRUD with no transformation
- Budget does not support middleware licensing
When Middleware Wins
- 5+ systems in the integration landscape
- Complex data transformations or orchestration
- Regulatory requirements for audit trails and governance
- API program serving multiple consumer teams
- Need for centralized monitoring and error handling
The Break-Even Analysis
For CTA scenarios, articulate the break-even point:
- At 3 integrations: Middleware cost exceeds benefit — direct is cheaper
- At 5-6 integrations: Costs are roughly equal — middleware if growth is expected
- At 8+ integrations: Middleware pays for itself through reuse and centralized operations
3. Real-Time vs Batch
How fresh does the data need to be?
| Dimension | Real-Time | Batch |
|---|---|---|
| Data freshness | Seconds | Hours |
| Infrastructure cost | Higher (always-on connections) | Lower (scheduled jobs) |
| Resource consumption | Continuous API call burn | Concentrated during batch windows |
| Complexity | Higher (error handling, idempotency) | Lower (run, check, done) |
| Volume handling | Limited per-transaction | Optimized for large volumes |
| Failure impact | Affects individual records | Affects entire batch |
| Recovery | Record-by-record retry | Re-run entire batch or failed subset |
When Real-Time Wins
- Call center agent needs current customer data during a live call
- Compliance requires immediate notification (e.g., fraud alerts)
- User-facing process blocks without external data
- Data changes infrequently but must be current when accessed
When Batch Wins
- Reporting and analytics that run on yesterday’s data
- Data warehouse synchronization
- Large volume data migration or reconciliation
- External system cannot handle real-time call volume
- Cost optimization is a priority
The Hidden Third Option: Near-Real-Time
Often the best compromise. Data arrives within minutes rather than hours, without the complexity of true real-time.
| Approach | Latency | Good For |
|---|---|---|
| Platform Events | Seconds | Event-driven business processes |
| CDC + subscriber | Seconds-minutes | Data sync to external systems |
| Scheduled Apex (5-min) | 5 minutes | Small-batch periodic sync |
| Micro-batch (middleware) | 1-15 minutes | Moderate volume, moderate freshness |
4. Platform Events vs Change Data Capture
The most confused technology choice in Salesforce integration.
| Dimension | Platform Events | Change Data Capture |
|---|---|---|
| Event definition | Custom (you design the schema) | Automatic (mirrors object fields) |
| What triggers it | Explicit publish (Apex, Flow, API) | Any record DML operation |
| Semantics | Business event (“OrderSubmitted”) | Data event (“Account record updated”) |
| Field change tracking | You include what you want | Automatic (changedFields header) |
| External publishing | Yes (API can publish into SF) | No (SF-generated only) |
| Retention | 24h standard / 72h high-volume | 3 days |
| Granularity control | Full control over payload | All-or-nothing per object |
When Platform Events Win
- Custom business events with specific semantics
- External systems need to publish events into Salesforce
- You need control over exactly what data is in the event payload
- The event represents a business occurrence, not a data change
When CDC Wins
- You need to replicate data changes to external systems
- Field-level change tracking is required (what changed, from what to what)
- You want zero-code event publishing (automatic on DML)
- Data synchronization is the primary use case
They are not mutually exclusive
A well-designed integration might use CDC for data synchronization and Platform Events for business process orchestration. Do not treat them as alternatives when they serve different purposes.
5. Build vs Buy Middleware
When considering whether to build custom integration infrastructure or purchase a middleware platform.
| Dimension | Build Custom | Buy (MuleSoft, Boomi, etc.) |
|---|---|---|
| Initial cost | Developer time only | License + developer time |
| Time to first integration | Weeks-months | Days-weeks (after setup) |
| Connector ecosystem | Build each connector | Pre-built connectors |
| Monitoring | Build or integrate separately | Included |
| Scaling | Must architect yourself | Platform handles scaling |
| Vendor lock-in | None | Tied to vendor |
| Maintenance | All on your team | Vendor handles platform updates |
| Team expertise | General developers | Requires platform-specific skills |
| Customization | Unlimited | Within platform capabilities |
When Build Wins
- Single, simple integration that will not grow
- Team has strong development skills but no middleware budget
- Unique requirements that no middleware handles well
- Regulatory restrictions on third-party platforms
When Buy Wins
- 5+ integrations in the landscape (ROI for pre-built connectors)
- Need centralized monitoring and governance
- Team is small and cannot maintain custom infrastructure
- Speed to market is critical (pre-built connectors save months)
- Compliance requires audit trails and governance that middleware provides
6. ETL vs ELT
Where data transformation happens matters for performance and complexity.
| Dimension | ETL (Transform Before Load) | ELT (Transform After Load) |
|---|---|---|
| Where transformation runs | Middleware / staging area | Target system (Salesforce) |
| Salesforce processing | Minimal (clean data loaded) | Higher (transformation in Apex/Flow) |
| Governor limit risk | Low (transforms are external) | Higher (Apex CPU, SOQL limits) |
| Transformation complexity | Unlimited (no governor limits) | Limited by Salesforce governor limits |
| Data quality | Validated before reaching SF | Bad data may enter SF, cleaned after |
| Load speed | Potentially slower (extra step) | Faster load, but slower post-processing |
When ETL Wins (Usually the Right Answer for Salesforce)
- Complex transformations that would hit governor limits
- Data quality issues that should be caught before loading
- Large volumes where Apex processing limits are a concern
- Multiple target systems need the same transformed data
When ELT Wins
- Salesforce-native transformation logic (formulas, flows)
- Transformations are trivial (field renaming, simple mapping)
- Data needs to be in Salesforce before business logic applies
- Leveraging Salesforce platform features for transformation
7. API Limits: Optimize vs Accept
How much effort to invest in reducing API call consumption.
| Strategy | Effort | When Worth It |
|---|---|---|
| Accept limits, buy more | Low effort, higher cost | When API consumption is well within limits |
| Composite API | Moderate effort | When multiple related operations occur together |
| Bulk API for volume | Moderate effort | When processing > 200 records |
| Event-driven (replace polling) | High effort | When polling consumes significant API budget |
| Caching | High effort | When same data is requested repeatedly |
| GraphQL | Moderate effort | When consumers over-fetch data |
Trade-off Analysis Template
Use this structure when evaluating trade-offs in CTA scenarios:
| Step | Question | Example |
|---|---|---|
| 1 | What is the business requirement? | ”Call center needs real-time customer data” |
| 2 | What are the options? | ”Sync REST callout vs async CDC + cache” |
| 3 | What does each option optimize for? | ”Sync: freshness. Async: resilience.” |
| 4 | What does each option sacrifice? | ”Sync: availability if ERP is down. Async: data might be 5 min stale.” |
| 5 | What does the scenario prioritize? | ”Call center SLA requires 99.9% uptime.” |
| 6 | What is the recommendation? | ”Async CDC with local cache. 5-min staleness is acceptable; ERP downtime breaking the call center is not.” |
| 7 | What is the mitigation? | ”Cache refresh triggered by agent if data looks stale.” |
Practice this template
Before the CTA board, practice applying this template to 10+ integration scenarios. The more you practice the structured analysis, the more naturally it will flow during the exam.
Related Content
- Data Modeling — data model complexity (polymorphic lookups, junction objects) directly impacts integration payload design and transformation trade-offs
- Solution Architecture Trade-offs — integration trade-offs are a subset of broader solution architecture trade-offs (build vs buy, on-platform vs off-platform)
- Dev Lifecycle Trade-offs — integration deployment complexity and testing trade-offs connect to release management decisions
Sources
- Salesforce Integration Patterns and Practices
- Salesforce Architect Decision Guides
- Martin Fowler, “Patterns of Enterprise Application Integration”
- Gregor Hohpe & Bobby Woolf, “Enterprise Integration Patterns”
- CTA coaching community trade-off analysis frameworks