The Shift from "Running" to "Architected"

When you first start a project, the goal is simple: Make it work. But as Workloop evolved, the goal changed: Make it unbreakable. Moving a full-stack application with real-time capabilities to AWS isn't just about moving code; it’s about designing a system that can handle traffic, protect data, and stay online 24/7.

Today, I’m pulling back the curtain on the Workloop Production Architecture.

1. The Network Backbone: VPC & Subnet Strategy

A flat network is a vulnerable network. To protect the Workloop backend and our MongoDB Atlas data stream, I designed a custom VPC with a strict "Privileged Access" model.

1. Public Subnets: These house our Application Load Balancer (ALB) and the NAT Gateway. They are the only parts of the infrastructure that "talk" directly to the open internet.
2. Private Subnets: This is where the magic happens. The Workloop-Server (EC2) lives here. It has no public IP. To download updates or talk to MongoDB Atlas, it routes outgoing traffic through the NAT Gateway using an Elastic IP.
3. The Benefit: Even if someone finds your server's internal IP, they cannot reach it from the outside. The only "front door" is the Load Balancer.

2. The Compute Stack: Docker-Powered Synergy

Instead of scattering services across multiple small servers, I utilized a high-performance EC2 instance running a unified Docker Compose environment.

1. Frontend (Port 80): Served via Nginx, optimized for fast delivery of our React UI.
2. Backend (Port 8080): Our Java/Spring Boot engine handling the heavy lifting.
3. Nginx Reverse Proxy: Acts as the traffic controller, routing requests between the UI and the API seamlessly.

Architect’s Note: Using Docker ensures that the environment I tested locally is identical to the one running in the AWS Private Subnet. No more "it works on my machine."

3. The Real-Time Challenge: WebSockets & Sticky Sessions

Workloop isn't a static site; it's a real-time chat platform. This creates a challenge for standard Load Balancers. Since WebSockets maintain a persistent connection, a standard "Round Robin" routing would break the chat.

The Solution: I implemented Target Group Stickiness on the Application Load Balancer. This ensures that once a user connects to the Workloop server, the ALB "remembers" them, keeping their WebSocket heartbeat alive without interruption.

4. Hybrid Data Flow: S3 & MongoDB Atlas

Data is the heart of Workloop. I chose a hybrid approach to ensure both security and performance.

1. Secure Media (S3): We moved from public buckets to a private fortress. By using an IAM User with AmazonS3FullAccess and S3 Presigned URLs, the backend generates a temporary "VIP Pass" for every image or file a user views.
2. Cloud Database (MongoDB Atlas): We use a secure SRV Connection String. By whitelisting the Elastic IP of our NAT Gateway in the Atlas dashboard, we ensure that only our Workloop-Server can touch the database.

5. The "Golden Ribbon": Route 53 & SSL

A professional app needs a professional address. I used Amazon Route 53 to manage the workloop.chat domain. To secure user data in transit, I used AWS Certificate Manager (ACM) to issue an SSL certificate.

The result? A secure, green padlock for every user, with the ALB handling the "SSL Termination" to keep the backend fast.

(https://workloop.chat) with a green security lock icon]

Technical Specification Summary

Conclusion: The Journey Continues

Designing this architecture taught me that being a developer is about writing code, but being an Architect is about writing the rules of how that code survives in the wild. From private subnets to presigned URLs, every layer of Workloop is now built for the scale of tomorrow.

Me: "VPC ID: Correct. Ports: Mapped. SSL: Active. S3: Private. MongoDB: Whitelisted."

My Brain: "It's not just an app anymore. It's a fortress. Now... is that coffee ready yet?"

What’s your go-to AWS service for production security? Let’s talk architecture in the comments!