Solution Architecture and Design
Adobe Campaign Classic architecture questions test whether you can map business requirements onto the platform's tiers and its place in the wider Adobe Experience Cloud. Know the core split: the application/marketing server (web UI, workflow engine, JavaScript interpreter, SOAP/HTTP APIs) and the database layer (typically PostgreSQL, Oracle, SQL Server, or Snowflake in hybrid deployments), plus message-center/execution instances for high-volume transactional and mid-sourcing for deliverability offload. Understand the marketing vs. mid-sourcing vs. execution vs. message-center instance roles and which workloads run where. Candidates must reason about on-premise vs. hybrid (Adobe-hosted database) vs. fully managed, and where ACS (Adobe Campaign Standard) differs from Classic - Classic offers schema-level extensibility and workflows that Standard does not.
Traps: questions that imply the web UI executes delivery rendering locally (it does not - the delivery server/message center does); conflating technical workflows (system, nms, xtk namespaces) with campaign workflows; assuming a single instance handles both batch and real-time messaging at scale. A frequent miss is underestimating how mid-sourcing changes tracking and deliverability architecture.
Rule of thumb: one database, one primary application server per instance; scale batch through workflows and DB tuning, scale transactional throughput through message center/execution instances. Worked example: a client needs 2M transactional API calls/day with sub-second latency and a separate 10M batch newsletter - design message center for the transactional path and keep batch on the marketing instance, sharing a federated data model rather than overloading one server.