Counter Caches

walker.bookings.count is a COUNT(*), every single render

WalkersController#walker_payload doesn't show a booking count today — but the moment a feature asks "how many bookings has this walker done," the obvious line is walker.bookings.count. That's not free: .count on an association issues SELECT COUNT() FROM bookings WHERE walker_id = ? — a real query, scanning (or index-scanning) every matching row, every single time you render it. List 20 walkers, show each one's booking count, and that's 20 extra COUNT() queries on top of everything else — the exact same shape as the N+1 from lesson 1, just wearing a .count instead of a lazy association load.

counter_cache — Rails keeps a column in sync for you

counter_cache: true on the belongs_to side tells Rails: maintain an integer column on the OTHER model that always holds the current count, updated automatically on every create and destroy. Read it back with plain attribute access — walker.bookings_count — no query at all, because it's just a column already sitting on the row you loaded.