Solution Architecture and Integration
Architecture questions ask you to choose a pattern and defend it. Learn four integration patterns: request-reply (a user or system calls Salesforce and waits, e.g., REST callout or SOAP API), fire-and-forget (Salesforce pushes data out via outbound messages, Platform Events or webhooks and does not wait), batch (scheduled bulk sync via the Bulk API or Data Loader), and remote call-in/data virtualization (external data read live through Salesforce Connect, no replication).
Know the APIs: REST for lightweight JSON CRUD and mobile; SOAP for formal WSDLs and enterprise contracts; Bulk API for very large volumes; Streaming/Change Data Capture and Platform Events for near-real-time event distribution; Metadata API for deploying configuration. Outbound calls from Salesforce require callouts with remote site settings or, better, Named Credentials for endpoint and authentication management, plus a Connected App for OAuth-based authorization and single sign-on for user authentication.
Governor limits shape designs: callout timeouts, daily API request allocations by license and edition, and the rule that a single transaction cannot make unlimited callouts - so middleware (MuleSoft or another ESB) is the answer when many systems must be orchestrated, retried or transformed.
Traps: choosing SOAP for a high-volume nightly sync where Bulk API is right; using outbound messages for real-time UI validation (they are asynchronous and not guaranteed for that purpose); forgetting authentication setup (Connected App, OAuth scopes, named credentials); assuming Salesforce Connect stores external data; ignoring multi-org strategy and license mix.
Worked example: ERP is the system of record for orders; Salesforce must show them and push new quotes for fulfilment - read ERP orders through Salesforce Connect or a scheduled Bulk API sync into a custom object, and push quotes asynchronously with Platform Events or a callout through a named credential, with retry handled in middleware.
Rule of thumb: name the system of record first, then pick the pattern by volume, latency and failure handling, then pick the API.