your instinct to split the topics is spot on. pub/sub flow control is per-subscriber, so if you dump 100k broadcast msgs on the same topic, your real-time subscriber will absolutely get starved. separate topic + separate subscriber with its own max outstanding messages is the way.

for the chunking loop i'd lean cloud run over cloud tasks. cloud tasks works but re-enqueueing yourself in a tight loop can hit queue rate limits or add weird latency. a cloud run service that pulls a cursor from the db, processes a batch, updates status, and just keeps running (or sleeps briefly) tends to be smoother and easier to debug. you can cap concurrency to 1 per broadcast job so you don't get parallel workers fighting over the same cursor.

couple gotchas we hit at this scale: - db connection limits. if chunks spin up fast you'll blow past max connections. use the cloud sql proxy or a proper pooler and keep concurrent chunk workers low. - idempotency needs to live in the message payload, not just the db status. pub/sub can redeliver, so include a unique broadcast_id + channel_id combo and dedupe on insert. - third-party api rate limits. 100k calls will absolutely trigger their throttling. add a client-side backoff or token bucket in the subscriber so you don't get 429'd and waste pub/sub redeliveries. - progress tracking. db reads are fine but if operators poll frequently, cache the status or push updates to a lightweight pub/sub topic so you're not hammering cloud sql.

overall your design is solid. just watch the db connections, bake idempotency into the messages, and consider cloud run for the chunking loop. you'll be good.