The limit you are thinking of applies strictly to a single, individual document, not the collection it lives in

• The Rule: You should not update or write to the exact same document more than roughly once per second.
• Why it matters: If 500 users all click a “Like” button at the exact same moment, and your code tries to increment a counter inside a single document (/counters/global_likes), the system will suffer from contention, throw errors, and drop writes.
• The Fix: Instead of writing to one document, you scatter those writes across a whole collection by creating a new document for every single “Like”. Collections are designed to easily swallow massive bursts of writes.

There is one specific scenario where a collection-wide write limit comes into play: sequential field indexing.

• The Rule: You should not exceed 500 writes per second to a single collection if the documents contain strictly sequential values (like an auto-incrementing ID, an ordered timestamp, or a alphabetical sequence) on an indexed field. [5]
• Why it matters: Firestore splits your data across multiple backend servers using index keys. If every new document has a timestamp exactly 1 millisecond later than the last one, Firestore is forced to send all those writes to the exact same physical server node, creating a “hot spot” that slows down the database.
• The Fix: Use Firestore’s default automatically generated alphanumeric IDs (e.g., hK39jLp2...), which are completely random and distributed evenly across database shards.

Because sub-collections are isolated underneath parent documents, their indexes are treated separately.

• If you have a root collection called comments and you are writing thousands of sequential timestamps, you might hit the 500 writes/sec bottleneck.
• If you break those comments out into separate sub-collections under posts (/posts/{postId}/comments), each individual post has its own isolated sub-collection index, vastly scaling up your database’s overall write capacity.