How do you design a scalable data model in Firestore?

Firestore data modeling differs fundamentally from SQL: you optimize for read performance over normalization. Principles: (1) Design for queries first — start with the queries your app needs, then design the data structure to support them. Firestore can't JOIN documents; (2) Denormalization is expected — duplicate data to avoid fetching multiple documents. Store the author's name in each post document, not just the author's ID; (3) Choose between top-level collections vs. subcollections — subcollections for data that's only queried in the context of its parent; top-level collections when cross-collection queries are needed; (4) Fan-out writes — for social feeds, when a user posts, write to each follower's feed collection (write amplification, but enables O(1) reads per user); (5) Avoid large arrays — Firestore loads the entire document including arrays; large arrays slow reads and hit the 1MB limit; use subcollections instead; (6) Use aggregation documents — maintain counter/aggregate documents updated via Cloud Functions on writes; (7) Map fields vs. subcollections — maps work for bounded, small datasets; subcollections for potentially large, growing lists; (8) 1:N relationships — store the "many" side's parent ID as a field and query by it.