Educational Platform System Design

Migrating M** Education to a Customised Coding Platform

A hedge fund company client, M** Capital based in London, is planning to migrate its no-code educational platform, M** Education, to a coding-based platform for greater customisation. To support this transition, I designed an AWS cloud architecture and a database ERD based on the given requirements. The timeline for this task is three days. This is the architectural design part of the presentation I gave them.

Project Requirements

No restrictions on the technology stack
Unspecified user scale, but the platform does not appear to have a large user base
Features:
- A platform for students to find internships
- An interactive website
- User/member management system
- Login system for gated content
- Members can access webinar (video) content for free
- Paid membership packages with expiry periods (e.g., three months)
- Newsletter email functionality and newsletter template saved for frequent usage
Sitemap and wireframe exist but will not be shared to encourage a fresh perspective on the project

Designing a Scalable and Cost-Effective Architecture for a Read-Heavy Platform

1. System Architecture

For this website, the primary user interaction involves consuming company-provided content, making it a read-heavy system. Given this usage pattern, the architecture should prioritise efficient content delivery, scalability, and cost optimisation.

Optimising Performance with a CDN

To enhance performance and reduce latency, I would leverage a CDN to cache frequently accessed content. This approach ensures:

Faster load times by serving content from edge locations
Reduced server load by minimising direct requests to the backend
Lower bandwidth costs by offloading traffic from the origin server

Storage Strategy

Static Assets (images, videos, zip files) → Stored in Amazon S3
Access Control → Managed directly within S3 for fine-grained permission control

User Authentication

For platforms with fewer than 50,000 users, AWS Cognito is a simple choice as it provides:

Seamless user registration & authentication
Email verification via AWS SES
Token issuance upon login

However, for platforms exceeding 50,000 users, Cognito incurs additional costs. In such cases, handling custom token issuance isn’t particularly complex, making both options viable.

Token vs Session-Based Authentication

Using session-based authentication requires storing sessions in a database, leading to:

Increased storage costs
Complexities in scaling (e.g., multiple DB instances for auto-scaling)

To balance scalability and cost-efficiency, JWT-based authentication is the recommended approach as it’s widely adopted in modern architectures.

API Gateway for Future Scalability

To ensure the platform can extend to other services (e.g., finance-related features in the future), I recommend using AWS API Gateway for its:

Flexibility (easy integration with different backend services)
Scalability (fully managed and auto-scales seamlessly)

Backend and Database Choices

The choice of backend stack is flexible, but database selection depends on the language:

Java → Relational Database (RDS) (for stability, especially given the company's financial background)
Python/JavaScript → DynamoDB (serverless, event-driven cost model)

While DynamoDB is a cost-effective option (billing only for active requests), a Java-based approach using RDS might be preferable due to:

Better long-term stability for a finance company
Easier hiring process for Java developers

Backend Infrastructure Options

EC2 or Containers → Both are viable backend hosting options
API Gateway + Lambda → API Gateway is a fully managed system that auto-scales automatically with built-in load balancing

Since anyone (not just signed-up users) can subscribe, I would:

Store and manage email templates in AWS SES
Use EventBridge to schedule and automate email dispatch
Send emails via AWS SES

This approach ensures a scalable, cost-efficient, and well-structured architecture.

ERD Design

Handling Webinars

Since webinars are free to access, they should be stored separately from paid packages in the database. Webinars can be delivered in two ways:

Via YouTube links (if open access is acceptable)
Stored in internal storage (if access is restricted to members)

Since the business requirements are unclear, I would create a separate table to track webinar participants, allowing future analysis of engagement and user interactions.

Structuring the Payment System

The purchase flow consists of two components:

Shopping Cart System
Payment System

Shopping Cart Data Model

A user can have only one shopping cart → One-to-One relationship between User and Shopping Cart
A shopping cart can contain multiple cart items → One-to-Many relationship between Shopping Cart and Cart Items
Each cart item is linked to a specific package, but a single package can be associated with multiple cart items → Many-to-One relationship between Cart Item and Package

Order System

A user can place multiple orders over time → One-to-Many relationship between User (Account) and Order
An order can include multiple packages → One-to-Many relationship between Order and Order Items

Unlike regular user-based features, newsletter subscriptions are open to everyone—not just signed-up users.

To accommodate this, I would create a separate database table for newsletter subscribers
This allows both registered users and external visitors to sign up
For marketing purposes, I would store previously sent newsletters in a dedicated Newsletter DB table.