Server Architecture and Components
Core topology
Alteryx Server is a multi-tier system. The Controller (the AlteryxService) orchestrates work: it queues jobs, assigns them to workers, tracks state, and hosts the persistence layer (MongoDB for metadata and the Alteryx Service database for execution state). Workers are the engines that actually run workflows; they can be colocated with the controller or run as separate machines. A Gallery web front end (the AlteryxService web tier) serves the browser UI and the public API. A load balancer typically fronts multiple Gallery nodes when you scale out the web tier.
Concepts to know
Understand which component owns which responsibility: the controller schedules, workers execute, Gallery presents. Know that MongoDB stores users, permissions, workflows, schedules, and results metadata, while the Alteryx Service database stores execution and queue state. Know that the message queue (RabbitMQ in distributed deployments) carries job assignments between controller and remote workers. Understand that a single-node install collapses all roles onto one machine, which is why small deployments still "work" without separate worker nodes.
Traps
Questions love to blur controller vs. worker. A worker does not schedule; it receives assignments. The controller does not execute the workflow engine; it delegates. Another trap is assuming MongoDB holds execution logs - it holds metadata, not the raw engine logs (those live in the service logs directory). Also watch for answers that treat the Gallery as the scheduler.
Rule of thumb
"Who decides" = Controller. "Who runs" = Worker. "Who shows" = Gallery. "Where metadata lives" = MongoDB. Map every architecture question to one of those four buckets before answering.