100,000 students. One "Enroll" button. 🎓
Here's how I'd design the backend on AWS using serverless, events, and containers 👇
1️⃣ The request
Student → Website → API Gateway → Lambda
Lambda checks the basics: is the student valid, is the course open, is enrollment allowed? There's no server to keep running 24/7. It runs when a request arrives, and AWS handles scaling and patching.
2️⃣ The trap
Once enrollment succeeds, it's tempting to have Lambda call Payment, the student database, email, faculty alerts, and analytics directly. That's tight coupling. If the email service goes down, the whole flow can suffer.
3️⃣ The fix: publish an event
Instead of calling everyone, Lambda announces one thing: "StudentEnrolled" 📣
Lambda is the producer, EventBridge is the broker, and the Payment, Database, and Notification services are the consumers.
Producer produces → Broker distributes → Consumer consumes.
Want fraud detection or analytics later? Add a new consumer. The enrollment service doesn't change. That's loose coupling.
4️⃣ Where containers come in
Say the Payment service grows into Java, Spring Boot, libraries, and a payment SDK. Package it all into a container, then choose where it runs:
☸️ EKS if your team already runs Kubernetes
🚢 ECS if you want AWS-native orchestration with fewer decisions to make
5️⃣ Where Fargate fits (where many beginners get confused)
ECS and EKS decide how your containers are orchestrated. Fargate is the serverless compute underneath, so you don't manage, patch, or scale servers.
My one-line memory hook: Lambda = serverless code, Fargate = serverless containers.
What would you plug in as the next consumer of the StudentEnrolled event?
Top comments (0)