Performance, Scalability, and Sizing
Performance questions reward a bottleneck-first mindset: the database is usually the constraint, not the app server. Know how to read slow queries, missing indexes, table scans, and lock contention. Understand workflow concurrency (limit simultaneous heavy workflows), delivery throughput (how many messages per hour per server and per MTA), and the impact of broadLog/trackingLog growth on the database. Candidates must reason about archiving/purging (data retention workflows), partitioning, and database maintenance (vacuum/analyze, statistics). Know message center throughput and mid-sourcing offload as scaling levers.
Traps: assuming adding app servers fixes a DB-bound workload; ignoring index bloat from over-indexing; forgetting that large queries without filters drag the whole instance; and misjudging delivery sizing - recipients × frequency × size drives MTA and bandwidth, not just recipient count. Another classic: confusing throughput (messages/hour) with latency (time to first send).
Rule of thumb: size to peak hour, not daily average; keep broadLog retention tight and index filter columns. Worked example: a 5M-recipient send in a 2-hour window needs ~2,500 msg/min sustained - verify MTA capacity and DB write throughput for broadLog inserts, and schedule purges so the log table doesn't balloon, rather than simply adding a second app server.