ALLEN Platform Design Tenets

ALLEN Digital has started on a journey to revamp the core platform and build it grounds up. We want to lay a strong foundation while starting on this journey and ensure we build a truly robust, reliable, secure, scalable and maintainable platform.

Goals

Some of the high level goals our platform components should enable are -

• Onboarding: It should support all existing use cases across offline and online product offerings of ALLEN.

• New Offerings: It should be a simple and low effort to launch newer learning cohorts in future in addition to supporting existing learning cohorts of JEE, NEET and PCNF across platform components. Other type of offerings could also be online-only courses e.g. PG NEET which does not have any class, batch format.

• Experimentation: It should be simple to launch, un-launch and measure the results of experiments for cohorts to test features.

• Secure & Access Controlled: User data and interaction is secure and private, company IP is safe and protected. Learning content/material (including videos, study material, questions, tests) access should be available on a need to know basis only.

• Data Privacy: User (students and parents) data should be stored securely and privacy needs to be ensured so that performance insights and other sensitive data we collected or generated are not leaked and are accessible to those with required permissions.

• Performance: The performance of the consumer facing components should be fast, delightful and ensure high quality based on the best possible performance for the consumer device and internet capabilities.

• Robust: Feature addition should be easy and flexible, software should be well tested.

• Reliable: Components are stress tested and fault tolerant, upgradable without downtime. Systems should not be the hindrance for students aiming to use them for studying. The platform should be adequately monitored and easy to debug issues. 

• Elastic Scalability: Components would be horizontally scalable or easily modifiable for scalability, components would scale with demand elasticity.

• Maintainable: Automation should be used extensively for testing and deployments ensuring easy maintainability and simplified overall operations all across the platform components.

• Debuggable: Components should emit key metrics and logs to enable easy debugging of customer facing and internal issues. Cross component tools that stitch an end to end view helping trace the source of the issues in the whole funnel needs to be built. 

Tenets

The tenets are prefixed with FE, BE or ALL to denote if they specifically apply to frontend, backend or both. 

• [ALL] Multi-tenancy: For all components to be built, multi-tenancy should be designed for. By multi-tenancy, it means, it should be possible to launch new instances of the same components for different cohorts and configurations if required. E.g. tenants in user service could be a combination of Business Entity (ALLEN NEXT, Reliable), Country(India, UAE etc).  We should bake the concept of tenant in our service APIs, entity data model and overall storage layer.

• [ALL] Horizontal Scalability: All components should be designed for easy horizontal scalability. All the stack choices should enable this and if we are choosing something that does not provide the same, then at application level logic, we should seed the aspect of horizontal scalability in the bare minimum possible way. E.g. Some basic shard-ing logic in data model and application layer when going with mysql assuming only 1 shard to begin with enabling us to migrate to more shards in future.

• [ALL] Multi-lingual: All components should be built and tested to support multiple languages from the get-go. Ensure unicode string usage across and test for the same in unit and integration tests.

• [BE] Resource oriented public API design: APIs that the frontend apps will interact with should follow a resource oriented design as described by the Google AIP foundation here: AIP-121: Resource-oriented design  

• [BE] Service owned Data Security: Each service owner is responsible for securing the data they own, store and vend out to requestors. Each service needs to authorise the access to the data to the requestor and APIs should not take user information as request parameters but rely on AuthN and AuthZ service to provide local libraries to provide user context from the access tokens. E.g. no user id in the request parameter but read from the access token by decrypting the JWT.

• [BE] Encryption at Rest and in Transit: All data transmitted on http and/or tcp over the network and stored in the databases and object stores should be encrypted. 

• [FE] Optimised Performance: Frontend components should load only the required artefacts for each experience and employ compression over the wire to limit the bandwidth utilisation.

• [ALL] Lazy Loading: Backend components should retrieve and load only the required data from storages only when needed. 

• [ALL] Data Transmission: Data transmission over the wire has to be thought through across the application. At any time, students bandwidth consumption and prioritisation of packets are to be managed e.g. in cases like low bandwidth data transmission only restricted for video consumption etc.

• [ALL] Dynamic Configuration: Components will build mechanisms to consume dynamic configuration to enable feature and capability modification without requiring full deployments.

• [ALL] ACLs: All components and the resources exposed by them should be ACL controlled and authorisations should be in place to ensure controlled and secure access.

• [ALL] Automation: All code should fully automate the operational tasks of building, testing and deploying the software.

• [ALL] Cautious Logging: Components will log bare minimum data for debugging purposes. Components will emit metrics and use the right level in logging statements (debug, error, fatal). Components will NOT log any user and otherwise sensitive data.

• [ALL] Metrics Dashboard: All components should have a dashboard of metrics available to monitor and alert for key events. This should enable debugging and cross platform stitching too.

• [FE] Bundle Size: App download and web bundle size should not exceed target size. Every new integration should take care of size as an important criteria.

• [FE] Cold Startup: App/Web cold startup time should not exceed threshold.

• [FE] Framerate: UI FPS should not drop due to any heavy loading, animations etc. It should ideally support 60 FPS min.

• [ALL] Vendors: All vendors and their services should be hosted and available in India region from latency perspectives and compliance perspectives in some cases.

Explore our career page for more information on how you can be a part of changing the Indian education system lnkd.in/gyZiNZXv