A chalk talk is a conference session with a lot of interactivity. The speakers ask questions to the audience, draw diagrams on a whiteboard, and the audience asks questions back to the speakers.

That's one of my preferred session types when I go to AWS re:Invent.

Here I chose one I attended in 2025 to explore a few techniques I use with GenAI and architectural diagrams.

I also took the opportunity that Claude Opus 4.6 is out and already available within Kiro CLI (an equivalent to Claude Code at AWS) to push this forward.

1. From Picture to Diagram

During a chalk talk (like that could happen in any architecture session), the AWS architecture is hand drawn.

In this particular session named "Beyond micro services: Event-driven patterns for modern applications", we designed a web site backend, and for scalability reasons we wanted to use an EDA (Event Driven Architecture) workflow to process shipment events (a parcel was shipped for example).

Here is a picture I took of the architecture during the session:

On the red path, we can see that an application calls an API gateway, then we put the ship event in an SQS queue, which is read by a Lambda function, that writes to a history DynamoDB table, and an EventBridge bus, which triggers a notification to the user via SNS.

The transformation prompt

First I started kiro-cli, uploaded my photo in the IDE and chose the Claude Opus 4.6 model...

...and asked:

Create a diagram from 20251205_085619.jpg

The result

I obtained a nice mermaid diagram in a markdown file as you can see below.

Mermaid is a diagram as code notation that allows describing diagrams with text.

However, I prefer to use Drawio because I can easily add modifications in my diagram with my mouse using Drawio Extension in Kiro-IDE (an IDE based on VSCode open source extension, maintained by AWS).

So, I asked

Create a drawio diagram from architecture-diagram.md using 2025 icons

Which gave me this result:

N.B.: I could also ask to directly generate a Drawio diagram from the picture.

2. From Picture to Diagram - Second Version

Then during the chat talk, after some discussions we made this architecture evolve.

So, I uploaded another picture and asked the same kind of questions which created another Drawio diagram of the architecture:

Create a drawio diagram from architecture-diagram-v2.md using 2025 icons

Why did we update the initial architecture?

You may ask yourself, why did we change our minds?

This is quite common in design and architecture, the first idea that comes to mind is not always the best one, even if you have a lot of people in the room😊

Simply ask Kiro why we replaced a part of the diagram

If it's not obvious (and it's not for a lot of people) you can simply ask kiro-cli.

Why Event Driven Shipping flow has a better architecture in architecture-diagram-v2.drawio than in architecture-diagram-v1.drawio?

The answer was quite impressive because that's exactly the reason why we changed our mind during the chalk talk, here is a chunk of the LLM answer:

The Lambda only writes to DynamoDB. The event propagation happens automatically through the stream and pipe.

Here's why that matters across several architectural characteristics:

1. Data Consistency (the biggest win)
- v1: If the Lambda writes to DynamoDB but the put_events call to EventBridge fails (timeout, throttle, transient error), you have data in DynamoDB but no event was published. Consumers never learn about the shipping update. The system is in an inconsistent state.
- v2: The Lambda does a single write. The DynamoDB Stream guarantees that every successful write produces a stream record. EventBridge Pipes reads that stream. There's no dual-write — the event is derived from the data, not published separately.

...

The dual-write problem

So, in brief, in the first architecture the problem is that the lambda writes in both Event Bridge Bus and DynamoDB Table.

That's a trap we can easily fall into because technically... it works.

However, as you may know, software is not 100% reliable and it can happen that you send a notification to the customer, but (due to an unexpected error) you don't write to the DynamoDB table. That means that you will have an inconsistent state in your system.

For example, your customer might receive an information and your customer support team doesn't see the same information. That will make things confusing for your users if they have to talk to each other.

That's the 'dual-write' problem.

In the picture below we have that dual-write (the lambda writes in DynamoDB and Event Bridge)

Solving dual-write problem

In the picture below we have NO dual-write (the lambda writes in the DynamoDB table only)

The solution is to write the message in one place only, not more. In this case the user will receive a notification only if each step of the process was successful.

That's why we added a DynamoDB Stream, and an EventBridge Pipe that can pull messages from the DynamoDB Stream and write to the Event Bridge Bus (EventBridge Pipes avoid maintaining a lambda for that).

N.B.: For EDA experts, later in the chalk talk we added a dead letter to store the failing messages.

From diagram to code

A technique I find very useful is to generate the CDK (Cloud Development Kit) code from my diagrams.

The generated CDK code can be executed in order to build a template that can be deployed to AWS CloudFormation (an Infrastructure as Code Engine), which atomically creates all the components on AWS. You can find more about this here

That's super powerful.

1. Create a Kiro steering file

So, First I created a steering (i.e. rule file) that I call my ProfesionnalTwin

---
inclusion: always
---
<!------------------------------------------------------------------------------------
   Add rules to this file or a short description and have Kiro refine them for you.

   Learn about inclusion modes: https://kiro.dev/docs/steering/#inclusion-modes
-------------------------------------------------------------------------------------> 
- I work with python 3.10
- I work with CDK V2
- I work in AWS eu-west-1 region

2. Generate code from the diagram

Then, I used Kiro CLI and asked:

architecture-diagram-v2.drawio generate "Event-Driven Shipping Flow" application

And after a few minutes I got that kind of code

3. Deploy the generated application

I ran a 'cdk deploy' and the deployment worked right away.

4. Generate an end-to-end test

Testing an EDA workflow is not easy, but I can rely on Kiro-CLI for that, so I asked:

Create a test that will put a message on the sqs queue and verifiy the workflow output

It generated a test suite that I could execute to verify the workflow was working:

Prevent dual-write: From Characteristics to Fitness Functions

Listing architecture characteristics

Architecture has characteristics (security, scalability, ...), so I asked what sort of the characteristics Kiro CLI could identify in this architecture

What architecture characteristics can I identify in my shipping flow architecture

Architecture characteristics I can identify:

1. Scalability / Elasticity
- All components are serverless and scale independently (SQS, Lambda, DynamoDB on-demand, EventBridge)
- No provisioned capacity or concurrency caps anywhere

2. Loose Coupling
- Components communicate through events, not direct calls
- SQS decouples the upstream order management from the shipping-update Lambda
- EventBridge bus decouples the DynamoDB state change from downstream consumers (SNS, event-handler Lambda)
- Adding new consumers requires only a new EventBridge rule — no changes to producers

...

Listing fitness functions

If you want to prevent a drift of your architecture characteristics (scalability reduction, security reduction, ...) you can use what we call "Fitness Functions".

These are static or dynamic tests that will verify the compliance of your architecture with its characteristics. That's super important if you want to make your architecture evolve while minimizing risks.

So, I asked:

What fitness functions can I create for these characteristics?

Based on the characteristics I identified, here are fitness functions you could create beyond the scalability ones you already have:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


## Loose Coupling — Static

- **EventBridge bus exists between producers and consumers** — ensures no direct Lambda-to-Lambda invocations
- **No Lambda environment variables referencing other Lambda ARNs** — proves components don't call each other directly
- **EventBridge rule count matches expected consumer count** — detects accidental tight coupling through hardcoded targets

...

Visualize your fitness functions

To better visualize what fitness functions are and where they apply in my architecture, I simply asked Kiro

Create a new Drawio diagram from architecture-diagram-v2.drawio with representation of the implemented fitness functions

The result is an updated diagram with all the fitness functions (it's focused on scalability only in this case).

For example, for the application to be scalable we shouldn't use FIFO queues (they have limited throughput compared to standard queues), and during runtime, message age should be less than 60 seconds.

Prevent dual-write problem with a fitness function

I asked an implementation of the previous scalability fitness functions, but I also wanted to focus on our dual-write problem.

This fitness function should spot this issue in the future if someone (including me) wants to make the architecture evolve and forget about this.

What fitness function can I implement to avoid dual-write implementation?

## Static — CDK Assertions

Lambda functions have at most one write permission — if a Lambda has grant_write_data to DynamoDB AND grant_put_events_to on EventBridge, that's a dual-write risk.

python
def test_no_lambda_dual_write():
    """Lambdas must write to at most one destination — use streams/pipes for fan-out."""
    template = _template()
    resources = template.find_resources("AWS::IAM::Policy")

    for logical_id, resource in resources.items():
        statements = resource["Properties"]["PolicyDocument"]["Statement"]
        write_actions = set()
        for stmt in statements:
            actions = stmt.get("Action", [])
            if isinstance(actions, str):
                actions = [actions]
            for action in actions:
                if any(w in action for w in [
                    "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:BatchWriteItem",
                    "events:PutEvents",
                    "sqs:SendMessage",
                    "sns:Publish",
                ]):
                    write_actions.add(action.split(":")[0])

        assert len(write_actions) <= 1, (
            f"{logical_id} has write permissions to {write_actions} "
            f"— dual-write risk. Use DynamoDB Streams + EventBridge Pipes instead."
        )

The result is a test suite containing CDK Assertions.

Actually, the test will scan my CloudFormation template and detect if the lambda is allowed to write to more than one target service.

Therefore in the future if someone updates the lambda with a new target, the test will fail when executed locally or in the CI/CD pipeline.

Continue talking to your diagram

There are multiple ways you can continue to use your diagram to extract some information or generate others.

Here are a few examples, and I don't think I'm exhaustive here:

Show Architecture Patterns

Maybe you prefer to work with EIP (Enterprise Integration Patterns), or at least identify these patterns, for a better communication or simply generalize your architecture in order to use it on another platform.

Here is an example of what you can do:

Redraw a new shipping flow with Enterprise Integration Patterns

We see for example that the shipping update lambda function is a 'Message Translator', EventBridge a 'Publish/Subscribe Channel', ...

Show Architecture Constructs

Having a monolithic piece of code to describe your architecture can have some advantages, but for reuse purposes you might want to split this into modules called CDK Constructs in the CDK vocabulary.

You can ask for some help from Kiro for this

Create a new drawio diagram from architecture-diagram-v2.drawio with well defined constructs

Then you can adjust this diagram to your needs and ask Kiro to update your CDK code from your Diagram.

Compute Architecture Cost

Another way you can use your diagram is to estimate the cost of your architecture.

In order to be accurate, I installed the AWS Pricing MCP Server

Then I asked

architecture-diagram-v2.drawio how much would this shipping flow cost with 10000 events per hour

And I got a report with the cost breakdown

Conclusion

Chalk Talks are really interesting and fun. The one I'm talking about in this blog post was the opportunity to learn more about AWS Services and Event Driven Architecture (EDA).

That was also the opportunity to explore the Kiro CLI capabilities with pictures & diagrams. Especially with the new Claude Opus 4.6 (I guess with can get quite similar results with Claude Sonnet 4.5 by the way).

That led me to explore more techniques, like asking why an architecture is better than another one. Then list architecture characteristics, generate fitness functions, and prevent from architecture flaws in the future (the dual-write problem in this case).

When I see all these possibilities, I really feel that we'll be able to build more sophisticated software more easily and software architect jobs will get more and more exciting!