I think we may want to provide a bit more descriptive information around how a handoff is confirmed by the middlemanager when it makes a call to the coordinatorClient in order to release a task for completion in the documentation provided by druid. This seems to be somewhat of a blackbox for folks that are new to druid and may not understand exactly what all API calls are performed to and from the middlemanager -> coordinator to determine if a task can be released for handoff completion (see isHandoffCompleted method the middlemanager calls to the coordinatorClient for completion state https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/client/coordinator/CoordinatorClientImpl.java). This can often cause long handoff times (on larger clusters where there are millions of segments, often upwards of 30-40 minutes for a real time task) as the coordinator appears to fetch the segments status from cached metadata versus performing a lookup against the DB during api call to resolve whether or not the segment is already available on the cluster. Often DB tuning tends to reduce this issue assuming everything else is running optimally on the cluster. I am curious if there are additional ways to reduce segment handoff times that should be documented for new operators. • Configuring chatAsync = true on supervisor tasks • Tuning the metadataDB for better select query performance (modifying buffers, disabling query cache etc...) • Tuning segment metadata retrieval period on the coordinator (defaults to every 1M for finding new segments) • Modifying the coordinator.poll.period to capture the state of the cluster in memory more frequently • enabling batchSegmentAllocation • SmartSegment handling (with 27.0.0) • etc....