OneHook Sub-Millisecond Event-Driven Direct-to-Cloud AI-Moderated NoSQL Profile Service Serverless Architecture

If you are a new developer stepping into the tech industry, building a “User Profile” seems like the easiest task in the world. You create a database table with columns for a first name, last name, and a bio. You write a simple server to save the data. Job done, right?

Not quite. When you are building a real-time, high-stakes platform — like the backend architecture we are finalizing for the OneHook platform ahead of our November 2026 launch — a profile service is far more than a simple CRUD (Create, Read, Update, Delete) application. It involves handling heavy media, asynchronous moderation, privacy controls, and maintaining sub-second latency.

I am sharing this architectural blueprint to demystify system design for learners. We will look beyond the code and explore how different cloud components harmonize to bring a massive profile service to life, and the critical engineering choices you have to make along the way.

The Big Picture: How the Components Harmonize

In a modern serverless architecture, you don’t just have one massive server doing all the work. You have specialized managed services that pass data between each other like a relay race.

Client Device
  |
  +-- (1) Auth & Routing --> API Gateway + Cognito
  |
  +-- (2) Compute ---------> AWS Lambda (Java)
  |
  +-- (3) Storage ---------> DynamoDB (Text Data)
  |
  +-- (4) Media -----------> Amazon S3 (Direct Uploads)
  |
  +-- (5) Events ----------> DynamoDB Streams & EventBridge
  |
  +-- (6) AI Moderation ---> Rekognition / Transcribe (Async)

Here is how a single profile update flows through this ecosystem:

1. The Gatekeeper: A user tries to update their bio. The request hits an API Gateway, which uses an identity provider (like Cognito) to verify the user’s token. If they aren’t who they say they are, the door stays shut.
2. The Brain: A small, stateless Lambda Function wakes up. It doesn’t store anything itself; it simply enforces business rules. It checks if the new bio is too long, structures the data, and prepares it for saving.
3. The Vault: The Lambda writes the data to DynamoDB, a lightning-fast NoSQL database. But the journey doesn’t end there.
4. The Ripple Effect: The moment data hits DynamoDB, it triggers a DynamoDB Stream. This is an event bus that broadcasts a message to the rest of the cloud ecosystem: “Hey, a profile just updated!”
5. The Background Workers: That broadcast wakes up other services asynchronously. For example, an AI moderation worker picks up the new bio, checks it for toxic language using NLP (Natural Language Processing), and writes a safe/unsafe status back to the database — all without making the user wait on their phone.

Engineering Choices That Define the System

System design is about evaluating different paths and picking the one that best fits your goals. Here is a look at three major architectural crossroads we faced and why we chose the paths we did.

Balancing User Experience with Content Safety

When a user uploads a new profile picture or bio, we need to ensure it is safe and free of inappropriate content. Running AI image recognition and text analysis takes anywhere from 1 to 5 seconds.

If we hold the connection open and force the user to watch a loading spinner while the AI runs, the app feels incredibly sluggish. Instead, we adopted an Event-Driven Architecture to handle this heavy lifting in the background.

We save the profile instantly with a flag marking it as PENDING_MODERATION. The API immediately returns a success response to the client, providing a snappy, sub-millisecond experience. Crucially, our read models enforce a strict privacy boundary: this unmoderated content is completely hidden from other users until the AI explicitly approves it. In the background, DynamoDB Streams trigger the AI tools. If the content violates our guidelines, a background worker deletes it. We accept a brief window where the uploading user might temporarily see their own image on their screen that gets removed shortly after, entirely to ensure the user interface remains lightning-fast while protecting the wider community.

Rethinking Large File Uploads

Profiles require users to upload heavy assets, like 5MB high-resolution images and 50MB video introductions.

Sending a 50MB video through our API Gateway and backend Lambda functions would be disastrous. It consumes expensive compute time, risks network timeouts, and creates a massive bottleneck for other users trying to access the service.

To solve this, we utilize Direct-to-S3 uploads via Presigned URLs. Our lightweight backend Lambda never actually touches the video file. Instead, it generates a “Presigned POST Policy” — a temporary, cryptographically signed ticket. This ticket gives the user’s phone permission to upload exactly one file, of a specific size, directly to an Amazon S3 storage bucket. This approach completely removes the heavy file-transfer burden from our backend compute layer, massively increasing scalability and reducing costs, even though it requires slightly more complex logic on the mobile app.

Choosing the Right Database for the Job

A profile service handles millions of fetch requests daily as users discover each other.

While traditional SQL databases (like PostgreSQL) are fantastic for joining complex tables, they can slow down under massive, distributed scale. We opted for DynamoDB, a NoSQL key-value store.

In a profile service, the access pattern is almost entirely strict key-value lookups: “Get me the profile for User 123.” DynamoDB excels at this, providing single-digit millisecond latency regardless of whether you have ten profiles or ten million.

Because a NoSQL database does not support complex ad-hoc queries easily (e.g., “Find all users aged 24 who like badminton and live in this zip code”), we had to design our database schema specifically for how the app requests data. To maintain performance, we completely decoupled our search and matching engine from the profile storage, letting each system do exactly what it does best.

https://acrobat.adobe.com/id/urn:aaid:sc:ap:a9ec5826-107f-42a7-8b01-73fcc82d533d ← Detailed Architecture

My Message to the Next Generation of Builders

To the new developers reading this: tutorials will teach you how to write code, but building robust systems requires you to think about data flow, edge cases, and user experience.

When you design a service, ask yourself: What happens if this external API takes 10 seconds to respond? What happens if a user uploads a 1GB file? What happens if two users update their profile at the exact same millisecond?

The transition from a junior developer to a systems architect happens when you stop obsessing over which framework to use, and start obsessing over where your data lives, how it moves, and the engineering choices you make to keep the system resilient.

The tools to build world-class, globally scalable infrastructure are all available to you today. Now, go build something incredible. — Pushp

Know about me: https://www.pushpsood.com/

Connect with me: https://www.pushpsood.com/links