There is something clarifying about sitting in a room full of people who are learning — genuinely learning, not performing expertise. The AWS Serverless Immersion Day was exactly that kind of room. An eight-hour, hands-on event hosted by AWS and presented by Kevin Draai, a former colleague and one of the sharpest serverless minds I know. Kevin is a Senior Delivery Consultant and a true expert in the space.

I have worked extensively with serverless architectures. I know Lambda, I know DynamoDB, I understand event-driven patterns at a level that would have made it easy to fill the silences with my own commentary. I chose not to. I held back deliberately — to let others absorb, to let Kevin's facilitation do its work, and to see what I might learn when I stopped performing what I already knew.

It was one of the better decisions I've made in a room.

The Event

The immersion day was designed to give software developers, engineers, DevOps practitioners, and system administrators their first real hands-on experience with core AWS serverless services. The agenda moved through introduction, account setup, and then into labs — building a serverless order processing system that touched:

• AWS Lambda
• Amazon API Gateway
• AWS Step Functions
• Amazon DynamoDB
• Amazon Simple Queue Service (SQS)

The use case was a tax return processing system — a real-world scenario that grounded the abstractions in something tangible. By the end, participants had deployed a working application across multiple AWS services and could see how the pieces connected.

What I Took Away

Eight lessons. Some technical, some architectural, some about how to be a professional in a room.

Lesson 1: You Don't Need to Know Everything

Open yourself up to learning. Never carry the expectation — placed on yourself or by others — that you should arrive already knowing. The moment you stop performing expertise is the moment you create space for real insight. I came into that room with years of serverless experience and still found things worth absorbing. Humility is not weakness — it is how you stay sharp.

Lesson 2: Choreography and Orchestration Are Not the Same Thing

This one deserves a clear definition because the industry conflates them constantly.

Orchestration means a central service coordinates the interaction and order in which services are invoked. Choreography means events flow between services without any centralised coordination.

In orchestration, communication is tightly controlled — you know the sequence, you own it. In choreography, services react to events without a conductor. Neither is universally better. Most mature applications use both, deliberately, for different use cases. Knowing which pattern to reach for — and why — is a mark of architectural maturity.

Lesson 3: Infrastructure Timing Matters More Than You Think

During the lab, we observed that new tax return submissions were being approved — but previous submissions remained stuck in a state of TaxReturnSubmitted. The reason: until the infrastructure for that module was deployed, events were never forwarded to the Step Functions state machine. They had nowhere to go.

This is a subtle but important production reality. Deployment order and infrastructure readiness directly affect event processing. Design your systems to handle events that arrive before the infrastructure is ready — or be explicit about the window in which they will not be processed.

Lesson 4: Minimise Blast Radius

This is a design principle that applies at every level of a serverless architecture — from IAM permissions scoped to least privilege, to function boundaries that limit the surface area of any single failure. When something goes wrong (and it will), the question is how much of your system goes with it. Thoughtful decomposition is not just good architecture — it is risk management.

Lesson 5: Amazon CloudWatch Synthetics

This one stopped me. CloudWatch Synthetics allows you to create synthetic transactions — scripted simulations of real user activity against your web applications or APIs. You can use these to continuously test performance and availability in production, test functionality before deployment, check for broken or dead links, and run visual monitoring against a baseline.

You are not waiting for a user to find the problem. You are the user — continuously, automatically, at scale.

This shifts the observability conversation from reactive to proactive. For public-sector applications in particular, where citizen trust is on the line, this capability is significant.

Lesson 6: CloudWatch RUM — Real User Monitoring

Where Synthetics simulates, RUM observes. With CloudWatch Real User Monitoring, you collect client-side performance data from actual user sessions in near real time — page load times, client-side errors, user behaviour patterns, and breakdowns by browser and device.

The distinction is worth holding: synthetic tests tell you what should work. RUM tells you what does work, for real users, on real devices, in real conditions. Both are necessary. Neither is sufficient alone.

Lesson 7: Review the AI/ML Services Offering

AWS has an extensive AI and ML catalogue that most engineers have not fully explored. The lab touched on how these services — including generative AI — can be layered onto serverless, event-driven architectures to augment human decision-making and improve user experience. If you have not recently reviewed what is available, carve out the time. The pace of change means your mental model of what AWS offers is probably already out of date.

Lesson 8: Microservices Architecture Is the Way to Go

The lab illustrated this not through slides but through the lived experience of building something. When a component fails, it fails in isolation. When a service needs to scale, it scales independently. When a team needs to move fast, they move on their slice of the system without waiting for others. The tax return system we built — eighteen Lambda functions, thirty log streams, ten buckets, five stages, six stacks — demonstrated the density and composability that microservices make possible.

The Architecture We Built

The system assembled across the workshop was genuinely instructive as a reference architecture for public-sector applications:

• Vue.js frontend files stored in Amazon S3, served via a CloudFront distribution
• Amazon API Gateway REST API for read access from the frontend, integrated with Lambda via proxy
• A second API method integrating directly with an SNS topic, which fans out to SQS — with a Lambda function retrieving messages and inserting into DynamoDB
• DynamoDB Streams implementing change data capture (CDC), forwarded via EventBridge Pipes to an EventBridge bus for downstream consumers

The SNS topic in front of SQS is a deliberate choice — it provides a fan-out mechanism for future queues without architectural rework. That kind of forward thinking is what separates a system that scales from one that struggles.

What the Day Proved

Serverless, event-driven architecture on AWS enables public-sector organisations — and really any organisation — to increase agility, reduce cost, and reduce risk. Orchestration, choreography, and streaming are not competing approaches. They are complementary tools, each suited to different problems in the same system. Granular, transaction-level monitoring is achievable and necessary. Data lakes can be built quickly on AWS to break down silos and drive actionable insight. And AI/ML services, including generative AI, are ready to be layered in — not as experiments but as production-grade capabilities.

I already knew most of this. What the day gave me was a fresh reminder of why it matters — and the value of staying in the room, staying quiet, and letting others find their own way to the same understanding.

Expertise is not about filling every silence. It is about knowing which silences to protect.

Thank you, Kevin. The room was better for having you in it.