> For the complete documentation index, see [llms.txt](https://sunbird.gitbook.io/sunbird-spark/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sunbird.gitbook.io/sunbird-spark/learn/tech-overview/design-principles.md). # Design Principles Sunbird Spark is built on five core architectural principles. Understanding these principles helps adopters make good decisions about how to deploy, configure, and extend the platform. {% stepper %} {% step %} **Microservices thinking** Spark is not a pre-packaged monolithic application. It is a set of generalised microservices — "Lego blocks" — that can be composed into many different solutions. Each microservice exposes a well-defined API. An adopter can use the content APIs to build a custom learner-facing application in React, while still using Spark's backend services for content management, search, and tracking. Another adopter might use only the question bank building block to add assessments to an existing application. The reference implementation — the Spark portal and mobile app — is one way to compose these services. It is not the only way. {% endstep %} {% step %} **Unbundling for diversity** Spark exposes hundreds of APIs covering content creation, collection management, user management, enrolment, progress tracking, certificate issuance, search, telemetry, and more. Each API is designed to be general-purpose — not tied to a specific domain or workflow. For example, the Collection API is abstract enough to represent a school textbook, a corporate training course, a healthcare protocol library, or a government policy document archive. The concept of "collection" is not specific to education. This unbundling means adopters can reimagine solutions using Spark's building blocks in ways that the original designers didn't anticipate — and they regularly do. {% endstep %} {% step %} **Loose coupling for evolution** Spark's building blocks are not tightly dependent on each other. The Knowlg building block (content management) can be deployed and used without the Lern building block (user management and enrolment), and vice versa. This decoupling means: * Adopters can start with a subset of building blocks and add more over time * Individual building blocks can be upgraded independently * A failure in one building block does not cascade to others * Adopters can replace individual building blocks with their own implementations, as long as the API contracts are honoured {% endstep %} {% step %} **Observability through emit, not extract** Every Spark microservice is built to **emit** telemetry as a first-class design concern — not as an afterthought. Every user interaction, every API call, and every system event generates a structured telemetry event that flows through the telemetry pipeline automatically. This is contrasted with "extract" architectures, where data is pulled out of application databases and logs after the fact. Extraction is brittle, privacy-risky, and operationally expensive. Emission is native, consistent, and privacy-safe (PII is masked at the point of emission). **The result**: a Spark deployment generates comprehensive usage data automatically, without any additional instrumentation work by the adopter. {% endstep %} {% step %} **Lean by default, scale on demand** Spark ships with the minimum viable set of services running. Features that are not universally needed — the full analytics pipeline, discussion forums, QR code infrastructure, project and observation management — are disabled by default and can be enabled as add-ons. A fresh Spark installation runs approximately 60% fewer services than Sunbird ED 8.x. This dramatically reduces both the infrastructure cost (target: \~$800/month for 100k users / 10k DAU) and operational complexity for the adopter. When an adopter needs to scale — or when they need a specific add-on capability — those services are available and have been proven at population scale (DIKSHA: 260M users, 2B+ events/day). The architecture does not need to be redesigned to scale; it needs more infrastructure. {% endstep %} {% endstepper %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://sunbird.gitbook.io/sunbird-spark/learn/tech-overview/design-principles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.