DEV Community: thekloudwiz

Designing a Serverless Order System on AWS (Beyond CRUD)

thekloudwiz — Thu, 23 Apr 2026 22:28:49 +0000

Most applications start as simple CRUD systems - create, read, update, delete. But the moment you try to model something that reflects real-world operations, that simplicity disappears.

I set out to build a basic ordering app, but somewhere along the way, I realised the real problem wasn't placing orders, it was handling what happens after.

This is a breakdown of how that shift happened and how I designed it using a serverless architecture on AWS.

At the beginning, the idea was straightforward.

A customer visits the site, browses the menu, places an order, and that’s it. But that “that’s it” didn’t sit well with me.

Because in a real setting, placing an order is just the starting point. Someone has to prepare it. Someone has to hand it over. Someone has to track what’s going on.

So I moved on from the whole simple ordering app to an actual system that handles things end-to-end.

Order lifecycle and system flow

The system ended up revolving around a defined order lifecycle.

Online orders go through the full flow, starting from PENDING, while walk-in or phone orders (handled by a waiter) start directly at PAID.

Each stage represents an actual step in how the business operates, so transitions are controlled rather than free-form.

How orders move through the system

Orders can come from two places.

One is the customer-facing app. The other is the waiter interface, which acts like a POS for walk-ins and phone orders.

Regardless of where they come from, everything goes into the same system and follows the same flow.

Once an order is placed and payment is confirmed, it becomes visible to the kitchen. From there, it moves through preparation, becomes ready, and then gets handled based on whether it’s pickup, dine-in, or delivery.

Keeping everything in one flow avoided a lot of fragmentation early on.

Role-based responsibilities

Instead of allowing anyone to update anything, I split responsibilities across roles.

The chef handles preparation. The waiter handles dispatch, serving, and delivery. The admin and manager oversee operations and manage users. The customer just initiates the process.

This might sound obvious, but enforcing it properly makes a big difference. It prevents conflicting updates and keeps the workflow predictable.

System architecture on AWS

On the infrastructure side, I went with a serverless setup on AWS.

The frontend is hosted on S3 and delivered through CloudFront. All API requests go through API Gateway into Lambda functions, which handle the business logic. Data is stored in DynamoDB.

Here’s a simplified view:

Other services fit around this core.

Cognito handles authentication and roles. Secrets Manager stores API keys. Payments are handled through Paystack. Emails are sent via SES/Brevo (as a fallback).

Most of the infrastructure setup was handled using Kiro, which helped speed up provisioning and kept things consistent as the system evolved.

Data modeling with DynamoDB

DynamoDB forced a different way of thinking.

Instead of designing tables around entities, I had to think about how the data would be accessed.

The most common queries were things like:

what’s currently preparing
what’s ready
what’s out for delivery

So the structure was built around that.

Orders include fields like status, createdAt, serviceType, and linkedTo. A secondary index on status makes it easy to fetch orders in a particular stage without scanning the entire table.

Handling real-world user behavior

One part that got complicated was user behavior.

A customer places an order, then comes back to place another. Now the system has to decide what to do with that.

Do you treat it as a separate order? Do you link it? What if the service type is different?

I ended up adding a linking option to let users decide whether to merge orders or keep them separate. There are also restrictions-once an order reaches a certain stage, you can’t change things like service type anymore.

That keeps things from breaking operationally.

Kitchen and dispatch workflow

The kitchen view is simple on purpose.

New orders appear in a single section. Orders being prepared show up in another. Each order has a timer, so it’s easy to see how long it has been sitting.

The waiter interface takes over after that.

It handles dispatch for pickup orders, serving dine-in customers, and managing deliveries.

It also handles orders that never came through the website in the first place.

Everything still ends up in the same system, which keeps things consistent.

API design and state enforcement

The backend is not just CRUD.

Every action goes through validation.

You can’t skip states. You can’t move an order to completed if it hasn’t been prepared. You can’t change certain properties once the order is too far along.

Each role can only perform specific actions.

That turned the backend into more of a state machine than a typical API.

Lessons learned

Most of the complexity in this project didn’t come from the infrastructure. It came from trying to match how things actually work in the real world.

Defining the order lifecycle was one thing. Handling edge cases—like multiple orders, changing service types, or different order sources—was where most of the effort went.

Enforcing rules at the backend made a big difference. It’s easy to rely on the frontend to guide users, but that falls apart quickly. Once the backend enforces the flow, things stay consistent.

Working with DynamoDB also required a shift in thinking. It’s less about structuring data neatly and more about making sure your queries are efficient.

Finally, splitting responsibilities across roles wasn’t just about access control. It shaped how the system behaves and prevented a lot of conflicts.

Closing thoughts

This project didn’t become interesting because of the stack.

It became interesting when it started behaving like something that could actually be used.

Once multiple people interact with a system, and actions happen at different times, structure becomes necessary. Without it, things fall apart quickly.

If you’re building something similar, it’s worth asking:

Are you just exposing endpoints… or are you designing how things actually work?

Watch Demo Video Here

Hello World; You Don’t Qualify for the AWS Community Builders Program

thekloudwiz — Wed, 24 Dec 2025 00:56:23 +0000

Why “Hello World”?

Because this is every beginner’s first program, and it feels like the right place to start my first text post on this platform.

And why “You Don’t Qualify for the AWS Community Builders Program”?

I’m fairly certain that title is what made you click. But I’m equally certain that by the time you finish reading, you’ll understand exactly why it makes sense.

Before we get into the reasons, let me start with a bit of background.

Growing up, I lived in a compound house. If you know that lifestyle, you understand that community was not optional, it was built into daily life.

You were not raised by only your parents. Any adult old enough to be your parent could correct you, guide you, or step in when needed.

We shared food, responsibilities, and sometimes even discipline. There was a sense of security that came from knowing someone was always looking out for you.

That environment shaped how I think about community to this day.

And this is exactly what the AWS Community Builder Program represents.

About AWS Community Builders Program

The AWS Community Builders Program offers technical resources, education, and networking opportunities to AWS technical enthusiasts and emerging thought leaders who are passionate about sharing knowledge and connecting with the technical community.

Interested AWS builders are encouraged to apply to build relationships with AWS product teams, AWS Heroes, and the wider AWS community.

Throughout the program, AWS subject matter experts provide informative sessions, share insights on new and existing services, and offer best practices for creating technical content, increasing reach, and effectively sharing AWS knowledge across online and in-person communities.

The program accepts a limited number of members each year, and all AWS builders are welcome and encouraged to apply.

With that context, let’s ask the real question.

Do You Qualify for the Program?

At least, not in the way you probably think you do.

If your idea of “qualifying” for the AWS Community Builders Program is having multiple AWS certifications, years of production experience, or a large online following, then yes — by that definition, you don’t qualify.

And that misunderstanding is exactly why many people who should apply never do.

I know this because I almost disqualified myself before I even understood what the program was about.

What I Thought the Program Was

I joined the AWS Community Builders waitlist in late December 2024, and in hindsight, I can confidently say I had no idea what I was doing.

I didn’t know when the application window opened, what the selection criteria were, or what the program truly represented. At the time, I wasn’t even sure what being a “Community Builder” actually meant in practice.

The truth is, I joined because of a mentor.

During a Cloud Engineering bootcamp, I was under the tutelage of Mawuli Denteh, and at some point, he casually mentioned that he was an AWS Community Builder and encouraged us to read about the program. There was no pitch attached to it, just a passing statement.

In my head, I made a very naive assumption: I have an AWS certification, so I probably qualify.

So I went online, searched “apply for AWS Community Builder,” clicked the first result, and discovered that applications were not even open. There was only a waitlist.

I joined it and moved on with my life.

I didn’t read about the program afterward.

I didn’t research past cohorts.

I didn’t study what AWS was looking for.

What I did instead was continue learning, building small projects, and sharing what I was learning through YouTube videos and short articles. At the time, I saw this as nothing more than personal documentation and a way to help others who might be behind me on the same path.

It wasn’t until early January 2025, when the application window opened, and I sat down to read the actual questions, that things finally clicked.

The application wasn’t asking, “How good are you?”

It was asking, “How have you been showing up for the community?”

Now this leads to the next question.

What Really Is The AWS Community Builders Program?

The AWS Community Builders Program is often misunderstood, so it helps to be very clear about what it is — and what it is not.

What It Is

The objective of the program is to support people who are already contributing to the AWS ecosystem in meaningful and consistent ways. These contributions can take many forms, including but not limited to:

Writing technical articles or tutorials
Creating educational videos or demos
Speaking at meetups or events
Mentoring others in the cloud space
Sharing lessons learned from real-world projects

AWS does not bring people into the program to start contributing. The program is designed to amplify and support work that is already happening.

What It Is Not

To avoid confusion, it is equally important to say what the program is not.

It is not a certification program.
It is not a hiring pipeline.
It is not a reward system for passing AWS exams.

Who Is the Program For?

The AWS Community Builders Program is a strong fit if you naturally do some of the following:

Share what you are learning, even while still learning it
Help others understand AWS concepts in simple, practical ways
Document your journey publicly through blogs, videos, talks, or posts
Contribute consistently, even if your audience is small
Care about community growth, not just personal branding

You do not need to be widely known.

You do not need thousands of followers.

You do not need a long list of certifications.

What matters most is evidence of genuine contribution.

Who Is the Program Not For?

There is a saying, “What is good for the goose is equally good for the gander.”

Well… maybe not.

It may not be a good fit if your primary motivation is:

Getting a badge, title, or LinkedIn headline
Accessing swag or exclusive perks
Joining first and “figuring out contribution later.”
Treating community involvement as transactional

This is not a criticism — it is simply a matter of alignment. The program works best for people who already see community as a responsibility, not an accessory.

Common Misconceptions

A few misconceptions arise every year, and they often deter good candidates from applying.

You need many AWS certifications.
Certifications can help, but they are not the deciding factor.
You must already be popular or well-known.
Consistency and authenticity matter far more than reach.
You must be an expert.
Many Community Builders are early- or mid-career professionals.
Selections are random.
They are not. Your application reflects your history of contribution.

Why You Should Apply

Beyond the visible benefits, the real value of the AWS Community Builders Program lies in what it enables over time.

Being part of the program gives you:

Access to a global network of practitioners who genuinely support one another
Opportunities to grow your voice, confidence, and clarity as a contributor
Encouragement to document your work, not perform expertise
Structure around something you may already be doing instinctively

Perhaps most importantly, it helps you realize that you do not need to “arrive” before you contribute. Growth and contribution can, and should, happen together.

What the Process Taught Me

Looking back, I didn’t get into the program because I understood it early. I got in because my actions happened to align with its values long before I knew what they were.

If I had to distill everything I learned into three principles, they would be these:

Live your truth

Do not manufacture a persona for an application. Be honest about who you are and what you care about.

Share your learnings

Teach as you learn. There will always be someone who benefits from your perspective. No project is “too basic” or “too advanced”.

Have a clear “WHY.”

Community Builder is not a title. It is a long-term commitment. Know why you want to be part of one.

If you are already doing these things, you may be closer to this program than you think.

Join the waitlist via this link