# Design a Hierarchical Learning Content API Design a backend API and database in which learning tracks contain modules and modules contain lessons. Explain data ownership, ordering, read and write endpoints, and how to avoid N+1 query behavior when returning a complete hierarchy. ### Constraints & Assumptions - Each child belongs to exactly one parent unless the design explicitly supports reuse. - Track, module, and lesson order must be stable and editable. - Fetching a hierarchy should use a bounded number of database queries. ### Clarifying Questions to Ask - Can one lesson appear in several modules? - Are drafts and published versions required? - What is the largest hierarchy returned in one request? ```hint Fetch by level, assemble by key Load each entity level in a bounded query and join it in memory, or use one carefully shaped relational query with deterministic ordering. ``` ### What a Strong Answer Covers - Normalized schema, foreign keys, ordering fields, and uniqueness constraints. - REST or equivalent endpoint contracts and authorization. - Eager loading, batched queries, joins or aggregation, pagination, and indexes. - Transactional reordering, caching, versioning, and deletion behavior. ### Follow-up Questions 1. How would reusable lessons change the relationships? 2. How would learner progress remain stable when content is reordered?