Dispatcher, Caching, and Performance
The Dispatcher is a caching/reverse-proxy layer in front of publish. Understand the cache model: content is cached on disk keyed by URL, with rules in dispatcher.any controlling caching (/rules), filters (/filter), and invalidations (/invalidate). Know the difference between cached HTML and clientlibs, and how statfileslevel and TTLs affect freshness.
Filters are critical: they allow/deny requests by path and method, protecting sensitive paths (/bin, /crx, admin endpoints). Understand the allow/deny ordering and that the last matching rule wins. Cache invalidation happens via flush agents that remove files matching patterns.
Performance concepts: caching headers, Cache-Control, the statfileslevel for auto-invalidation, and query-string handling (ignored vs cached parameters). Also understand that /etc.clientlibs with allowProxy is the recommended clientlib delivery path for the Dispatcher.
Traps: overly broad filters exposing admin paths; caching personalized content; forgetting to flush after replication; assuming query strings are cached by default (they're often bypassed). Another trap: statfileslevel too high causing excessive invalidation.
Worked example: to auto-invalidate cached pages when /content/mysite/en/page changes, set statfileslevel so the stat file sits at the right depth, and configure the flush agent to send invalidation requests.
Rule of thumb: deny by default in filters, allow only what's needed; never cache authenticated/personalized responses.