I have been completely obsessed with something that's been eating at me since I published "Master Software Architecture: A Pragmatic Guide."

Don't get me wrong, that book helped thousands of architects. But when I looked back at my first attempt at strategic Domain-Driven Design – "Mastering Strategic Domain-Driven Design" from late 2023 – I realized I could have done much better.

Sure, it hit 1,000 downloads in 24 hours and people loved that it was totally free. But I kept thinking that this is not good enough. You deserve better.

So I made a decision that probably sounds crazy to most creators. I completely stopped writing my newsletter and poured every ounce of my writing energy into rewriting that book from scratch.

Starting in March, I began what turned into a complete reconstruction—not a revision, not an update, but a total rebuild from the foundation up.

The original was good. This new version? It is the book I wish I had when I was struggling to understand why my software projects kept missing the mark despite perfect technical execution.

I am happy to share with you "Understand Your Domain First: An Introduction to Event Storming and Domain-Driven Design." I used some parts of the "Master Software Architecture” book in it (just that you know).

Most technical books teach you patterns and frameworks. This book teaches you how to think. It shows you how to look at a business domain and see the natural seams where your software should split, the workflows that drive real value, and the integration challenges that will emerge before they become expensive problems.

When you finish this book, you will know how to use Event Storming and transform the results of it into subdomains, bounded contexts and how to define a context map. Thanks to it, you will be able to understand any business domain deeply enough to build software that serves the business instead of fighting against it.

Download it, share it, use it to transform how you and your team think about software architecture.

And of course, let me know what you think :)

Today, I would like to share videos covering the same content.

Why is this topic so important to me? In general, I am lazy. I don't want unnecessary complexity when building projects. That is why I am skeptical of microservices, Redis, Kafka, and similar unless absolutely needed.

However, the world isn't black and white. Sometimes they are a perfect fit. But in my experience (30 direct projects, dozens of consulting gigs), they were truly justified around three times.

The videos dive into the same principles of keeping architecture simple, flexible, and focused on actual business needs rather than technical hype. You will get extended and practical insights on how to deal with complexity and how to focus on maintainability - all delivered in a format that might be easier to consume during your commute or coffee break.

If you found value in the written series, you will probably enjoy this alternative take on the same ideas. And if you are new to the concept of evolutionary architecture, either format will help you avoid the common pitfall of overengineering your next project.

How Did I Start Building Successful Apps - Evolutionary Architecture #1

In this video, I describe how I approach building successful apps by leveraging evolutionary architecture - a concept that grows and extends within time in your application.

How Did I Start To Focus On Simplicity In My Apps - Evolutionary Architecture #2

In this step - Simplicity - we are not reinventing the wheel. The goal is dead simple: build the most straightforward solution that works right now.

How Do You Keep Your Apps Maintainable - Evolutionary Architecture #3

At some point, we need to think about another aspect of our system - like how easy it is to maintain.

How Do I React To The Growth of My Apps? Evolutionary Architecture #4

At some point, you need to react to your app's growth. The number of users, requests, several development teams, and frequency of changes are common factors that help you decide whether to extract part of your application to microservices or wait a bit longer.

In this video, you will learn about four common decision factors that will help you. Make sure that you check them before deciding on microservices.

Hungry for more? Ready to see these principles in action? Check out my comprehensive 400-page book that walks through real-world applications. Grab it now with a 25% discount – offer valid only until the end of next week!

That's fine, but not enough to start technical implementation.

We still need to examine our business processes at a deeper level. Luckily, Event Storming comes with a solution called Process-Level analysis. At this level, we will focus on details—actors, commands, policies, and read models. Ultimately, we should have a clear map of our business processes, ready for a technical design.

Subscribe now

Before we start, I would like to introduce you to four new types of notes:

Command: It is usually pictured with a blue card. Represents an action taken by a user or system that changes the state of the domain. It is usually a verb or a verb phrase, like Prepare contract or Publish offer. Commands are crucial for understanding what actions can be performed in the system and what triggers these actions.

When you are adding commands, try to avoid having both a command and an event that basically say the same thing. Look at Process payment command and Payment processed event - they are just repeating each other!

Instead, you could have something like Validate payment details and authorize transaction as your command, which then leads to the Payment processed event. This cuts out the redundancy while still capturing what is happening.

Policy: It is usually pictured with a purple card. Represents a business policy that dictates what action should be taken under certain circumstances. Policies are typically derived from business rules or legal requirements. They guide the decision-making process within the domain and often lead to the generation of commands based on certain conditions.

Read model: It is usually pictured with a green card. Represents the result of a translation of a business event. It is the data a user or system needs to execute the action. Read models could still be a little bit vague, so treat them as a draft.

Actor: It is usually pictured with a yellow card. Represents a person or role interacting with the domain. Actors can be the initiators of commands or recipients of information. Actors help identify who or what is interacting with the system, providing insights into user roles or other entities that play a part in the domain.

Let's first check out how we handle offers. After digging deeper into this area, we have spotted some interesting things:

We have three actors:

• Sales representative who prepares the offer.

• Manager who provides feedback to the prepared offer.

• Marketing specialist who releases offer to the market.

who need to work together before an offer goes live. We also noticed something we missed in the Big Picture sessions - the offer approval process.

There are two policies:

• Revision handling policy which establishes how many revision cycles are permitted and timeframes for implementing changes.

• Offer publication standards policy which sets requirements for formatting, branding, and content that must be met before an offer can be published.

One more thing that came up was the Inquiry sent for an offer event - someone in the group started a discussion about whether this should be part of Offer Management at all. We couldn't reach a decision on this, so we tagged it as a hot spot to come back to later.

Next, we move to contract processing. This time we also discovered additional process that we missed during initial workshops.

Next, we move to contract processing. This time we also discovered an additional process - the compliance verification at the end was something we completely missed in earlier sessions.

We have four actors:

• Legal officer who drafts contract terms and conditions

• Sales representative who customizes contracts for specific customers

• Customer who reviews and signs the contract

• Compliance officer who ensures contract meets regulatory requirements

who need to work together for a contract to be fully processed. We noticed that the sales rep specifically handles customizing contracts for two types of customers: MVPs and renewals.

There are two policies:

• Customer classification policy which includes guidelines for identifying and handling MVPs and renewals, including special terms or expedited processing.

• Regulatory compliance policy that defines specific requirements that must be verified by compliance officers before finalizing contracts.

Next, we move to pass lifecycle management. This time we have added more detail to the flow based on our deeper understanding.

There are two actors: a manager who enrolls all passes in our system, and a security officer who initiates pass termination. We also find other events like Time elapsed and Security breach recorded. Additionally, we decided to replace Pass expired with Pass validity ended to be more clear.

There are two policies:

• Pass expiration policy which determines when and how passes should expire. It contains the business rules that define the conditions under which a pass is considered to have reached the end of its validity period.

• Pass cancellation policy which defines the circumstances under which passes should be cancelled for various reasons, the protocol to follow, and who has the authority to make such decisions.

Summary

As you can see, thanks to Process Level we are able to spot details that were missed during initial sessions. Our exploration of offer management, contract processing, and pass lifecycle revealed various important insights:

1. We identified key actors in each process and their specific roles:

2. We discovered missed processes:

   • The offer approval process in the offer management

   • The compliance verification step in contract processing

   • The security breach handling in the pass lifecycle

3. We properly structured our model by:

   • Avoiding command/event duplication

   • Adding policies between events and commands

   • Improving terminology for clarity

4. We identified important policies like:

   • Offer publication standards

   • Customer classification policy

   • Pass expiration policy

   • Pass cancellation policy

It helped us understand how actors cooperate through specific commands and events, giving us a much richer picture of our domain.

In the next post we will focus on describing subdomains based on what we modelled till now. Till then!

Plan your first workshop with decision-makers and domain experts - including developers (especially the ones who work on legacy systems as they often understand business processes deeply).

Subscribe now

Keep your workshop intimate with no more than 10 people (my rule of thumb). Working with a large system? Start with understanding your most vital workflow first. A medical practice might focus on scheduling, while an insurance company could tackle claims processing, and retailers might prioritize their ordering system.

Next, structure the workshop into shorter segments to maintain productivity. A typical 3.5-hour session includes:

• Three 1-hour blocks with 5-minute breaks

• 15-minute buffer at the end

Alternatively, you can plan six 30-minute segments with 5-minute breaks.

When modeling business processes, you will usually work with one of below states:

• As-is state (focusing and modeling the current process)

• To-be state (focusing and modeling the desired future state)

In my case, the modeling is usually done with either Event Storming or Domain Storytelling, or with a combination of both. There are also other techniques, so feel free to use the one that is comfortable for you, and what is most important - for participants.

In this post, I will show you how to leverage the power of Event Storming Big Picture workshops to start analyzing our fitness domain.

Think of Event Storming as your process detective kit. It helps uncover how things really work by focusing on completed actions – those 'done deals' in your business like Contract Signed or Offer Published. The magic happens in three layers.

It all starts with the Big Picture – a high-level map of events that shows what happens when highlighting any trouble spots. Next, you move to Process Level workshops where you focus on the details of the process - you will add actors, commands, policies, and read models. Finally, at the Design Level, you will explore modeled processes, focus on design, find aggregates, and refine business rules. At this level, pseudo-code may accompany sticky notes.

To handle such a workshop you will need plenty of wall space, sticky notes in different colors (static ones work best), and markers. Keep everyone on their feet during in-person sessions – it keeps minds sharp and ideas flowing. Running it remotely? Tools like Miro create that same collaborative feel.

For the Big Picture session, I usually use four types of notes:

• Event. It is usually pictured with an orange note. It represents every business event in our domain. It does not represent a technical event, so Button clicked is not something you should care about. The rule of thumb is to name it in the past tense (something happened) because it is an event that has already occurred and cannot be changed.

  

• Hot Spot. It is usually pictured with a red note. It represents every question or input that is unclear or cannot be answered during the workshop. This ensures that these concerns are not forgotten and can be addressed in future workshops.

  

• Comment. It is usually pictured with a yellow note. It represents additional information, clarifications, or observations that participants want to add to the conversation. They ensure that important information is not overlooked.

  

• External System. It is usually pictured with a pink note. It represents an external system that interfaces with the domain. External systems are not directly controlled by the modeled system but play a significant role in its operation. They may send or receive messages, data, or events to and from the system, influencing its behavior or being influenced by it.

  

Begin the workshop with practical preparation: equip everyone with plenty of colored notes and markers. Before diving into your business process, spend 30 minutes mapping something familiar, like a bike rental. It will help everyone grasp the techniques's basics.

With the team prepared, share your workshop's goal. In fitness, for example, you might aim to create a comprehensive view of membership enrollment and access management. Start the modeling by posting an orange event note centrally on your workspace. This first event – perhaps Contract Signed – becomes your temporal anchor, with the full process timeline growing organically in both directions: from offer selection through to pass registration and membership renewals.

Try to establish a 'no wrong answers' atmosphere where everyone feels confident contributing their process knowledge. When you spot similar events on the wall, pause for a quick alignment check – sometimes apparent duplicates are actually distinct events that share a name but serve different business functions.

Keep the momentum going with targeted questions: “What triggers this event?” or “What are the failure scenarios here?” When discussions hit an impasse, document it as a hot spot and move forward. That first hour should feel almost chaotic, with ideas flowing and sticky notes multiplying across the wall. If you are not seeing this energy, you either need to bring in different perspectives or provide more concrete examples to jumpstart thinking.

After the first part, the wall should look similar to this:

As you can see, there are both:

• Events that are related to business, e.g. Contract signed or Pass expired

• Events that are technical, e.g. Request sent to API or Button clicked

The first thing you want to do is to get rid of the technical events, as they are of no interest:

Time to arrange your event landscape chronologically. You can work forward – starting with the trigger event and following the natural flow of time, which matches how we typically think about processes. It helps capture fine details and reduces the risk of missing steps.

Alternatively, work backward from the final outcome. It often reveals unexpected connections and alternative paths you might miss going forward but it is easier to overlook intermediate steps.

After grouping, you should see an image similar to this one:

Now that you have your event timeline, it is time to identify the pivotal events that shape your process. Look for events that mark major transitions – where actions become hard to undo, like finalizing a payment, or where responsibility shifts between actors. These pivotal events often trigger new subprocesses or create natural process boundaries.

Each process will have several pivotal events, and they will help transform your linear 'snake' into something more meaningful:

It is worth mentioning that elements within each of the above groups should be closely related and focused on a specific purpose or business capability (high cohesion).

During the grouping, you might observe that there are unclear points, or participants want to add additional context to discussions. Mark them with hot spots (unclear points) or with comments (additional context):

Your final task is transforming those event groupings into named process segments. Hand this responsibility to your participants – they know their business domains best.

That is it. We are done with the high-level workshop. The result will be used during an in-depth Process Level workshop.

• E-commerce. This includes everything about online shopping, from showing products and processing orders to handling payments and more.

• Taxes. Covering stuff like income tax, and business tax, making sure people follow tax rules, and working with tax policies.

• Healthcare. Managing patient info, scheduling doctor visits, keeping medical records, handling prescriptions, and so on.

• Education. Involves things like tracking homework, running online learning platforms, managing student sign-ups, and grading.

• Logistics. Managing warehouses, moving stuff around, keeping track of inventory, finding the best delivery routes, and scheduling deliveries.

As you can see, it all depends on what industry you are in. Here is the interesting part - businesses in the same field often look pretty similar. They follow common patterns that show up again and again. But don't be fooled - even if they look alike, they never work exactly the same way.

That is why we need to really dig into understanding our business domain every time we build something new - or rebuild a legacy system.

Subscribe now

Our Business Domain - Fitness

So, imagine we have been hired to build an app that handles everything you can think of for a fitness studio. Sounds exciting, right?

Now, here is the thing - we can't just lock ourselves away, try to build every possible feature, and come back two years later with a finished product. That is usually a recipe for disaster - either we run out of money or end up with something nobody wants to use! Instead, we need to focus on creating a system that actually helps our customers and covers the most important stuff.

Great, but how do we figure out what these important processes are? Sure, we can use fancy techniques like Event Storming or Domain Storytelling. We will get different people together for workshops, brainstorm ideas, and map out how everything should flow.

But here is a secret - it usually starts way before that. It begins with ideas that come to you before you even think about planning workshops. Usually, you are invited to a meeting where someone tells you something like this:

• “We want to build a SaaS app that any fitness studio can use. It will handle everything - from making the first offer to planning diets.”

• “We need to create and promote offers to our customers. When someone wants to join or renew their membership, they will sign a contract.”

• “After they sign the contract, they will get a pass to access the studio.”

• “And when their pass expires, we need to be able to offer them a new contract.”

• “Oh, and we need some reports - maybe just showing how many passes we have sold to start with.”

And a hundred other inputs like these.

Now, you might feel overwhelmed. But actually, you are lucky - I have been in situations where teams were just told “Just make it like app XYZ!” and that was it.

That is what I call a red flag.

So why am I happy with getting this surface-level info without all the details? Because the details will come later in those workshops you will organize.

Let's break down what we have learned and how we can use it for our first workshops:

Starting with the first statement: “We want to build a SaaS app that any fitness studio can use...”

This tells us something important - we are probably building a SaaS (Software as a Service) app for fitness studios. It is technical stuff, but it shows the business model - how we plan to make money. Write this down - you will want to talk about it with your team after the workshops.

Why? Sometimes there might be better ways to do things, and part of your job is speaking up if you see a better approach.

Moving on to the next part: “We need to create and promote offers to our customers...”

Now we are getting our first real requirements, which we will dig into during workshops. Someone needs to create offers and show them to both new and existing customers. If someone likes what they see, they will sign a contract. This gives us a framework for planning our workshops and knowing what to focus on. Some questions that pop up:

• Will we build the entire offer system in our app?

• How will people see these offers? Through emails? In the app?

• What if someone wants a discount?

• Do they sign the contract online or at the studio?

These are all things to figure out when you meet with the domain experts and decision-makers. It is great that we are already thinking of these questions - write them down for later.

Looking at the next piece: “After they sign the contract...”

We can now see five main business processes:

• Creating offers

• Promoting offers

• Preparing contracts

• Signing contracts

• Registering passes

This last step - registering passes - happens after someone signs a contract. More questions to think about:

• How do customers get their passes?

• Can they get them different ways - like in person, by email, or in the mail?

These are all good things to bring up in future discussions.

Let's look at managing existing customers: “And when their pass expires, we need to be able to offer them a new contract…”

Aha! So when someone's pass is about to run out, we send them a new contract offer. This brings up more questions:

• What exactly counts as an expired pass?

• Should we make offers before passes expire?

• Should we include special renewal discounts?

• Could some contracts renew automatically?

Look at how much we have learned from just a short conversation. And this is just what we have thought of - imagine what will come up when you get everyone together to brainstorm.

The last part talks about reports: “Oh, and we need some reports…”

We want to track how many passes we are selling. This is another area to focus on. We should definitely check with the fitness studios about what reports they actually need. If nobody has asked them yet, that is a great question for the workshops: “Why haven't we talked to the people who will actually use this?”

Summary

This early analysis is valuable, and I really recommend doing it. It helps you:

• Get a head start on understanding what you are building

• Spot potential problems before they become real headaches

• Show up to workshops prepared with smart questions

• Save time by focusing on what really matters

When you break down conversations like this, you are not just collecting requirements but also starting to see the bigger picture of how everything fits together. Plus, it makes those upcoming workshops way more productive because you have already done some homework.

Next time you are starting a new project, try spending just an hour or two breaking down those initial conversations. You might be surprised at how many important questions and insights pop up, and your team will definitely appreciate having a clearer starting point for those deeper discussions.

Good software starts with good understanding, and every little bit of preparation helps build that understanding stronger.

I reached out to one of my mentors for advice. He said, "MJ, you need to get your hands on the Blue Book of DDD. Once you read it, everything will click. It is the best resource out there."

"Perfect, this should be straightforward. A couple of months of reading and I will have this DDD thing figured out," I thought to myself.

Subscribe now

I grabbed a copy. Now, nine years later, I can say it is worth its weight in gold. But - and there is always a "but" - it took me nine years of hands-on experience and reading other books (like the Red one) to reach the level where I am satisfied (but I am still learning!). Along the way, I have made every mistake: botched projects, misunderstood concepts, and architecture that were way more complex than it needed to be.

It has been an incredible ride, though I had to learn most lessons the hard way - through my own mistakes (and my team's).

Strategic Domain-Driven Design is not rocket science - it is not like quantum physics where you need to completely rewire your brain. However (yes, another "but"!), you do need to push past your comfort zone and break free from thinking purely in technical terms - all those providers, controllers, managers, and handlers.

The real key is understanding the business.

Getting Your Head Around the Domain

Every business has its domain - could be one, could be dozens, could be hundreds - where it operates and generates revenue. Starting at a new company or joining a new project can feel like drinking from a firehose - you are trying to prove your worth while juggling major decisions. It is like being thrown into a tornado of architecture diagrams, documentation, requirements, new team dynamics, and organizational politics. Even seasoned pros can get overwhelmed by this information overload.

With all this chaos, it is tempting to skip getting to know the business domain you are working in. Someone might tell you, "Don't worry, all the requirements are documented - we don't need to spend more time on business analysis."

This is exactly how legacy nightmares begin.

You need to be upfront about needing time to understand the domain and its processes - being new means you won't grasp everything just by reading documentation. You will need to run workshops - prepare for a few days for simpler businesses, possibly weeks (or months) for more complex ones.

Getting buy-in for this can be tough when you are still building trust. Usually, you get one shot at it. That first workshop has to deliver - if it is high-quality, gets people engaged, and sparks meaningful questions, you will have set the stage for future sessions. The key is to convince the others that it is really worth running it.

Running Workshops

So you are ready to kick off your first workshop. Priority number one is setting a clear goal - something concrete you can build on.

Typically, I focus on mapping out the most business-critical process - the one that will be at the heart of the system. Sometimes this process lives entirely in your system, sometimes pieces of it happen elsewhere. Take a process that includes submitting requests to government legal systems - you might have to wait weeks for a response before moving forward internally.

For this kickoff workshop, you want the heavy hitters - decision-makers who can actually approve changes, and domain experts who know the nitty-gritty of different areas (think logistics folks, accountants, sales teams, legal experts). If you are dealing with a legacy system, bring in the developers who have been in the trenches with it - they often understand the business logic better than anyone.

When planning the details:

• Group Size - I cap it at ten people. Any more and I can't give everyone the attention they deserve. Smaller groups tend to have better discussions and everyone gets a chance to contribute meaningfully.

• Location - While remote can work, I lean toward in-person meetings (even though in general I am a remote-first person). People are generally more engaged face-to-face, and it is easier to read the room. Plus, you can't beat physical whiteboards and sticky notes for collaborative work (I still love you Miro!).

• Timing - My sweet spot is three 1.5-hour blocks spread across two days. Often we need more time, but that is fine - I just schedule follow-up sessions. Short, focused sessions beat long, draining ones where people check out mentally.

Now you can start thinking about your approach. There are several proven methods but here are my favorite two:

• Event Storming - this technique gets teams exploring complex business domains by mapping out events, commands, policies, actors, read models, external systems, and more. It is particularly effective at spotting domain (you can also call it business) events and tracking how information flows through the system.

• Domain Storytelling - a workshop format where you listen to stories about how people and systems work together within their domain, and you visualize these stories with a simple pictographic language, making complex processes surprisingly clear. It is great for discovering edge cases and getting everyone on the same page about how things actually work.

It is also fine to combine both methods. I often start with Domain Storytelling to capture the big picture - it helps business stakeholders visualize how their processes flow at a high level (usually DS is a preferred way of doing it - don’t ask me why), and everyone can easily follow along. Once we have this shared understanding, I switch to Event Storming to dive deeper into specific processes we have identified.

This post is the start of the series related to Domain-Driven Design. In the next week, we will focus on discovering the fitness domain.

Subscribe now

But there is a catch. While we keep an eye on our own code, we don't have the same control over external packages. Whether they are open-source or paid ones, changes in their code might slip by unnoticed, creating security risks.

Let's say you need to validate API parameters in your application. Instead of writing this from scratch, you find a popular open-source library, version 1.34.0. It looks great - hundreds of thousands of projects use it, and your tests show it works perfectly.

But what if someone discovers a major security hole in version 1.34.0? The library team releases version 1.34.1 with a fix, but if your team misses this update, your application stays vulnerable. An attacker could use this known weakness to break into your system.

That is why keeping packages updated is crucial. Package providers often release updates to fix bugs and add features. But new versions can also bring their own problems - like version 1.35.0 accidentally introducing a new security flaw that goes unnoticed.

Watch out for "dead projects" too - libraries that nobody maintains anymore. These are more likely to have security problems. If you find one, switch to something else quickly. If you can't find a good replacement, consider building the feature yourself or even taking over the project's development within your company (e.g. by forking).

Be suspicious if a package that hasn't changed in years suddenly gets an update. This could be someone trying to slip in malicious code. Take your time to verify these unexpected updates before using them.

Such issues happen because your software is only as secure as its weakest part. Even with good monitoring, we might miss update notifications or not realize their importance. Sometimes we delay updates because they require big code changes.

One good solution is using tools like Dependabot in GitHub. It watches your dependencies and can even create automatic update requests. While this helps keep everything current, you still should check each update carefully. If you know an update might cause problems, plan time for it - especially if your current version has some security issues.

Another valuable approach is conducting monthly package audits. Set aside time each month to review your dependencies, checking for security advisories, recent updates, and overall package health. During these reviews, evaluate metrics like download counts, GitHub stars, and recent commits to gauge if packages are still actively maintained. Also, examine release notes and changelogs for potential security implications. This way you can identify risky dependencies before they become problems and it lets you plan migrations away from problematic packages well in advance.

How do you deal with keeping packages up to date?

I want to share the complete journey with you, answering questions like: How much has the book earned? Why did I choose the self-publishing route over a traditional publisher? How did I plan and execute the writing process? What were my initial expectations? How did I figure out the right pricing? And what are the pros and cons I have discovered along the way?

My hope is that by sharing this story—from its very beginning until now—I can help you make a good decision if you are considering writing your own technical book.

They say if you don't know where to start, start at the beginning. So that is exactly what I will do.

When Did I First Think About Writing a Book?

The story begins in 2012, at the start of my professional programming journey. Like any junior developer, my main concern was simply surviving another month without making a fool of myself. My knowledge was limited, but it was just beginning.

As the years passed, I found myself exploring various areas of software development. From infrastructure to backend, frontend to third-party integrations, I eventually became a part-time consultant (next to my full-time job) specializing in payment providers and authentication systems.

Each new project offered a different perspective on software development. I worked with legacy systems and greenfield projects, in both hierarchical and flat organizations, from small startups to large enterprises. Looking back, it is amazing how quickly time flew by and how much I learned from both my mentors and the challenges I faced.

Around 2020, my perspective on software systems fundamentally shifted. After witnessing numerous systems built with unnecessary complexity, I began focusing on two key principles: simplicity and evolution.

But let me be clear: simplicity does not mean stupidity. A well-designed system can adapt and grow, regardless of future changes. You can follow and adapt patterns to meet your business needs—whether that means starting with a simple App Service and later migrating to Kubernetes, or evolving today's modular monolith into tomorrow's distributed system.

I frequently received feedback like “I didn't think about it this way” or “It opened my eyes.” This was the trigger that inspired me to write a book, sharing my thought process that had proven successful in 80% of the situations I encountered. Of course, it will never be a silver bullet covering 100% of cases. When you hear about a “magical” method that is “the” way, remember it is just “a” way—one of many possibilities.

In 2022, I began collecting materials and created what I thought was a rough plan (though looking back, I would hardly even call it that). While I initially planned to write the book in 2023, a full-time opportunity in artificial intelligence—a field I had been interested in since my studies—took priority.

When 2024 arrived, I made a decisive choice: this would be the year I finally wrote my book. I left my full-time job to focus on this goal. Interestingly, I had two potential books in mind, so I created a LinkedIn poll to let my audience help decide which one I should write.

As you can see, the margin wasn't overwhelming—55% versus 45%. Still, the decision was made: “Ode To Software Architecture” would be my focus. That LinkedIn post on March 21, 2024, marked the beginning of what would become five months of intense work and dedication.

Self-Publishing Versus Traditional Publishing

One of the first crucial decisions you will face is choosing between self-publishing and working with a traditional publisher. Both paths have their advantages and drawbacks—what matters is understanding what is important to you and whether you can manage the self-publishing journey independently.

Here are the key factors I considered:

• Reach. If you don't have a significant following (like Gergely Orosz, for example), reaching a broad audience with your first self-published book can be challenging—I learned this the hard way. After publishing, I dove into research about typical sales figures. The pattern became clear: first-time authors typically sell 200-300 books in their first year. For a self-published book, reaching 1,000 sales in the first year is considered a success.

• Royalties. Based on publicly available information and discussions in the author community, traditional publishers typically offer an upfront payment of $3,000-5,000, with royalties of 5-8% on physical book sales and 10-20% on ebooks (sometimes after meeting certain sales thresholds). In contrast, self-publishing platforms (Leanpub, Gumroad, and others) offer 80-90% royalties on ebook sales. Physical book economics through print-on-demand services are less favorable (I earn something between $1-5 on each sale via Amazon KDP).

• Creative Freedom. Working with a traditional publisher involves extensive back-and-forth about content, writing style, and book structure. This makes sense—they have a reputation to maintain. For me, the ability to express myself naturally was paramount. I wanted to use simple language, share practical examples, and follow my specific structure. This was the deciding factor in choosing my path.

• Copy Editing. Traditional publishers include professional copy editing services. They will assign someone to review your manuscript for grammar, sentence structure, and phrasing. With self-publishing, you need to hire them independently.

• Beta Readers and Reviewers. Self-publishing means finding your own beta readers and reviewers. Surprisingly, this wasn't as difficult as I expected—I put out calls on social media, and several colleagues volunteered (some even approached me directly). Traditional publishers typically have established networks of reviewers.

• Marketing. While I can't speak comprehensively about traditional publishers' marketing support, they do offer built-in reach and reputation—almost everyone in tech knows names like O'Reilly or Manning. With self-publishing, you are responsible for all marketing efforts.

Having weighed all these factors, I decided to self-publish my book. The main challenge was finding the right platform that could help with reach, especially since I didn't have a large community behind me. After exploring my options, I settled on Leanpub. Their royalty structure was refreshingly straightforward: they take 20% of each sale (while taking care of things like collecting VAT), while 80% goes directly to the author. The platform's credibility was reinforced by the fact that many respected authors in the software architecture space—like Gregor Hohpe, Alberto Brandolini, and Simon Brown—had published their books there.

My Expectations

Before diving into writing, I did my homework. I studied other authors' sales figures, read countless posts about maintaining writing consistency, and consulted colleagues who had published their own books. Based on this research, I set clear goals:

• Sell 5,000 copies in the first year

• Start with an ebook, refine it based on early reader feedback, then release the physical version

• Write at least 20 pages daily, aiming for around 400 pages total

Was I being naive with these expectations? Let's explore what actually happened.

Writing

I started writing on March 22, 2024, just one day after the poll results came in. The first step was creating a comprehensive plan using a Miro board, mapping out topics and structure. While the overall plan proved accurate over time, some parts evolved (sadly, I no longer have that original Miro board). I spent about a week developing this initial outline, sharing it with my mastermind group (Radek Maziarka, Kamil Bączek, and Krzysztof Owsiany) and the “Order of Devs” Discord for feedback. Their input was invaluable and helped shape the final structure before I wrote my first word.

Initially, I tried maintaining a rigid schedule of writing eight hours daily. While I managed to keep this pace for 2-3 weeks, eventually I hit a wall. Creative work for such extended periods proved unsustainable, so I adapted my approach.

My new routine was simple: wake up, have coffee, and start writing. Some days were incredibly productive—I could write for 13-14 hours (my record was 16 hours), producing up to 20 pages. Other days, I might only manage 3-5 hours and 5 pages. I set just one rule: write at least 5 pages daily. In the entire writing period, I only fell short of this goal 3-4 times.

This approach worked wonderfully. The key lesson? Listen to yourself. When you can't write, don't force it. Find your own rhythm. Also, don't measure yourself against other authors.

If you don’t know it yet, my book is divided into 8 key steps and 2 extras:

• Step 1: Understand Software Architecture

• Step 2: Discover Your Business Domain

• Step 3: Recognize the Environment Around You

• Step 4: Choose Deployment Strategy

• Step 5: Define Release Strategy

• Step 6: Focus On Testing

• Step 7: Evolve Your Architecture

• Step 8: Don't Forget About Security

• Extra 1: Other Engineering Practices

• Extra 2: Architecture Exercises

My initial writing strategy was strictly sequential—starting with Step 1 and methodically moving forward. However, like my daily writing schedule, this linear approach ultimately proved too rigid. I discovered a more effective method: focusing first on topics I was most passionate about, such as discovering business domains, release strategies, architectural evolution, and security. I left the topics that interested me less, like deployment strategies and testing, for later. This approach clicked, and it served me well through the 5 months of writing.

Once I completed a substantial portion of each section, I sent it to my beta readers: Kamil Kiełbasa and José Roberto Araújo. I am incredibly grateful for their exceptional feedback. Their input helped me refine my ideas, fill in gaps, and most importantly, validate that my content was valuable and well-presented. I would then incorporate their suggestions and send the revised sections back for another review.

On March 28, I ordered my book cover through Fiverr. I received it two days later:

Throughout the process, I also actively engaged with both my LinkedIn community and colleagues, seeking input on technical aspects of the book. Here are some examples:

In April, Gergely Orosz gave me invaluable advice: regularly share draft excerpts from my book. This suggestion proved brilliant—it allowed me to publicly validate my content as I wrote. I continued this practice throughout the writing process, gaining feedback and building interest along the way.

In May, I hit my first major roadblock. I noticed my creativity had dried up—I was going through the motions of writing, but the quality was suffering. Rather than push through, I made a crucial decision: take a complete week off from writing. This proved to be exactly what I needed. When I returned to the keyboard, my mind was brimming with fresh ideas, and I easily found my rhythm again.

By the end of May, I began searching for a copy editor to elevate my book to professional standards. I had one key requirement: they needed to be from the United States, since I was primarily targeting US readers (below are my all-time stats from my Substack) and wanted American English.

I found my editor through Fiverr, and on June 10, 2024, I sent them the first 200 pages of my manuscript.

While waiting for the edited pages, I continued writing the next 200 pages. When the second crisis hit in June, I knew exactly what to do. I applied the same strategy—a week-long break—and once again, it worked perfectly.

I received the edited first half back on July 9, and spent several days reviewing the changes. On July 14, I sent the second batch of approximately 200 pages to my editor. While waiting for the second half, I made another significant decision: changing the book's title. I was receiving consistent feedback that “Ode To Software Architecture” didn't clearly convey the book's content. I created another poll to gather input, and that is how “Ode To Software Architecture” transformed into “Master Software Architecture.”

The last step before publication was securing reviewers who could provide rigorous, constructive feedback. Two experienced reviewers stepped forward: Jose Luis Latorre and Martin Dilger (author of the Leanpub bestseller “Understanding Eventsourcing”). I also specifically sought out Urs Enzler, knowing his reputation for thorough, unvarnished feedback would be invaluable.

Thanks to detailed critiques, I was able to make significant improvements to the book.

Throughout the writing process, I also gathered pricing feedback from multiple sources: social media interactions, direct inquiries, and Leanpub's data collection.

Based on this research, I initially structured the pricing with two tiers:

• Minimum price: $20

• Recommended price: $26

This flexible pricing model, unique to Leanpub, allows readers to pay the minimum price or choose to pay more if they find additional value in the book—there is no upper limit. After observing the market response, I later simplified the pricing to a flat $19, occasionally offering promotional discounts.

Finally, on August 26, the book was published.

Guest Authors

Rather than following the traditional approach of having one or two forewords, I invited five experts to share their perspectives on the key drivers of successful software architecture:

• Vladik Khononov. Author of “Learning Domain-Driven Design” and “Balancing Coupling in Software Design.” While we had known each other online, we finally met in person at Infoshare 2024 where we were both speakers.

• Oskar Dudycz. The “Leonardo da Vinci of Event Sourcing,” whom I have had the pleasure of knowing personally for several years.

• Milan Jovanović. A distinguished software architect and one of the two most prominent content creators in the C# and .NET ecosystem.

• Milan Milanović. Chief Technology Officer and well-known content creator.

• Denis Čahuk. Known for his pragmatic and smart approach to software development, Denis was previously a guest on my YouTube channel.

I am really happy and grateful to have them contribute to my book. Their insights add great value for readers, and honestly, seeing their names in my book still makes me smile.

The Numbers Behind the Book

After all the planning, writing, and editing, let's look at the results:

Readership

• Total readers: 810

  • Ebook copies: 728 (+11 refunds = 1.5%)

  • Physical copies: 82

Financial Results

• Leanpub royalties to date: $11,138.88

• Amazon KDP royalties: pending

Pricing Insights

During the period of the two-tier pricing model, the purchasing patterns were revealing:

• 65% of readers chose the minimum price

• 35% opted to pay above minimum

  • Most paid between $21-26

  • About 10 readers chose to pay even more

Time Investment

• Total hours: approximately 850

  • Pre-launch work: 753 hours

  • Post-launch activities: ~97 hours

Costs

• Copy editor: ~$1,000 (usually it costs between $1,000 and $2,000)

• Leanpub Pro Plan: $12.99/month

• Grammarly: $90/4 months (1x quarterly + 1x monthly plan)

• Deepl Pro: ~$10/month

• Facebook & Google Ads: $100

Reader Response

• Goodreads Rating: 4.83

Unexpected Surprise

Just days after publication, I received an incredible opportunity—an invitation from GOTO Book Club, probably the biggest tech book club in the world, to discuss my book in an interview. With their YouTube channel reaching 1 million subscribers, this was exactly the kind of exposure I was hoping for. The interview took place on September 6, just a week and a half after the book's release.

What made this even more special was that I could choose my interviewer. I invited Artur Skowroński, and we had a fantastic conversation. You can watch the recording here:

Final Reflections

Looking back, do I feel happy about publishing my first book? It is complicated. My initial goal was ambitious—5,000 sales in the first year. That turned out to be naive, but I am still on track to reach 1,000 sales, which I later learned is actually quite an achievement for a first-time self-published technical book.

The journey taught me invaluable lessons: how to write clear, accessible content, how to structure complex knowledge, and it significantly improved my written English. My beta readers and reviewers opened my eyes to new concepts I hadn't considered. And there is no better feeling than hearing someone say it is the best software architecture book they have read.

But I have to be honest—the writing process was exhausting. The creative aspect is a double-edged sword. It is incredibly engaging and interesting, but it drains your energy over the long run. At this point, I can't even think about writing another book.

Still, there is something incredibly rewarding about seeing a years-old dream become reality.

So, is writing a book worth it? Absolutely. Would I write another big book right now? No way—I am completely drained.

Good luck, and fingers crossed for your own writing journey!

How do you avoid drowning in this sea of information? How should you approach a testing strategy for your application?

There is no single answer – it all depends on a multitude of different factors. What I want to share with you is something of a personal diary – seven patterns I have noted over the years while building various applications. I hope it will help you decide which way to go.

Subscribe now

The following fragment comes from the testing strategy step in my Master Software Architecture book:

Theory is one thing; reality is another. You can blindly follow concepts, but what really matters is what works well in your specific context. Over years of working with various systems, I have gathered key observations that I would like to share.

Every time we prioritized integration tests over unit tests, we observed increased endpoint reliability and stability. However, this approach inadvertently resulted in a decline in code structure and its quality. The focus on overall functionality came at the expense of maintaining well-designed code at the chunk level.

When we focused too much on unit tests and too little on integration tests, we were able to keep our code well structured and it was easy to modify. The downside was that our endpoints often failed to perform as expected due to insufficient integration tests. Even though unit tests passed, we had many issues integrating multiple chunks.

Focusing mainly on end-to-end tests in greenfield applications almost always led to huge technical debt and, eventually, an inverted pyramid of tests. The plan was to start with end-to-end tests and gradually add other types of tests. However, this approach often failed because there was never enough time to add additional tests due to the constant addition of new features.

End-to-end tests have always been the most helpful for us when working with legacy projects. When no tests were in place, the easiest approach before refactoring was to cover key business processes with E2E tests. And when such tests did exist, they were the only way to understand how the process worked, especially in the absence of domain experts.

Flaky end-to-end tests often caused frustration and neglect. When there were hundreds or thousands (ouch!) of such tests, running them took several hours. Sometimes, some tests would fail randomly, so we had to rerun that part of the suite. Then they would pass, but we couldn’t be sure if other tests had affected the results. So we had to run them again, and then other tests failed. This led to a repetitive cycle of testing and retesting.

The amount of stuff we had to mock was a good indicator of how well our test was designed. Each time we needed many mocks, the test was unstable and useless. It was a trigger for us to review and redesign the code we were testing.

Shifting our focus to behaviors rather than all possible combinations resulted in the creation of more effective tests. By concentrating on the expected outcomes and interactions, we were able to develop tests that were well-structured, reliable, and easier to maintain. This behavioral approach allowed us to better align our testing with customer requirements.

As you can see, in some cases it is a game of trade-offs (similar to other topics related to software architecture). The key is finding the right balance for your specific context. Too much focus on integration tests might improve endpoint reliability but could impact code quality. Unit tests can help maintain clean, modifiable code but might miss critical integration issues. End-to-end tests could be invaluable for legacy systems yet potentially troublesome in other cases as they are slow and flaky.

Rather than dogmatically following a single testing approach or methodology, the most effective strategy involves carefully weighing these trade-offs against your project's unique needs, team dynamics, and business requirements. Remember that testing strategies should evolve as your application grows and changes – what works perfectly in the early stages of development might need adjustment as the system matures.

What are your observations when you come to the test topics?

Last year, I had the opportunity to speak at several conferences including Devox, Infoshare, .NET Day Switzerland, and DevConf. While I covered various topics, I found myself drawn repeatedly to one of my favorites: continuous deployments.

I still remember my first encounter with this concept. It left me both skeptical and fascinated. Skeptical, because I wasn't used to the idea of fully automating the entire software development cycle - no dedicated testing phases, no manual approvals, just rapid feedback loops. And at the time, every presentation I saw was purely theoretical. It wasn't a widely adopted practice yet, more of an aspirational goal than reality. Whenever I asked speakers about their actual experience with it, the answers were: "Oh, we have tried it in a test environment" or "Just for a hobby project."

Subscribe now

Being someone who loves turning theory into practice, I decided to look at this idea at the company I was working for several years ago. To my delight, it was approved, and we made it happen. In the end, everyone was quite happy with the result - customers, the company, and the developers.

That success led me to implement it in more organizations, including one large-scale with complex, established processes (yes, it was possible!). Each implementation brought its own challenges and experiences, teaching me invaluable lessons along the way.

Before going deeper, let's look at some eye-opening data. A study by SlashData and the Continuous Delivery Foundation tracked deployment frequencies across years, and the results might surprise you. Despite what the tech buzz on social media might suggest, the reality is quite different. Think continuous deployment is everywhere? The data tells a different story - only about 10% of surveyed teams deploy multiple times per day.

And you know what? That's perfectly fine. Continuous deployment isn't a one-size-fits-all solution - sometimes it simply doesn't make sense for a particular context, team, or product.

Anyway, coming to the heart of this post. I want to share with you the real mistakes we have been continuously making. Each one has taught us valuable lessons, but here is the honest truth: even after all these years, I can't claim to have found a perfect solution. While we have managed to make our deployments successful 98% of the time, there is still that 2% where human nature kicks in - someone forgets a crucial step, makes an unexpected mistake (yes, myself included!), and things go sideways.

Showing hidden features

Here is a classic pitfall we have run into time and time again: accidentally revealing features that were supposed to stay under wraps until a big marketing event. I can already hear you saying "But feature flags exist, you fool!" And yes, you are absolutely right - they do.

But here is the thing - even with four-eyes checks, about once every 20 or 30 deployments, someone (doesn't matter how experienced they are) forgets to add (or set) that crucial feature flag. And just like that... BANG! A feature that was meant to be unveiled at next month's marketing event is suddenly live for everyone to see.

Simple mistake, painful consequences. :)

Issues while touching a database

Now it is time for a particularly tricky challenge - managing database changes when you are running multiple versions of your application simultaneously (whether through blue-green, rolling, or canary deployments). The complexity here isn't in any specific type of change - it could be adding a column, changing a data type, or migrating data to a new structure. Your challenge lies in orchestrating these changes across parallel versions without breaking anything.

Every database change needs a carefully thought-out plan:

• First, map out your entry point - what is the very first change that needs to happen? This could be adding a nullable column or setting up a temporary transition state.

• Next, outline each subsequent step in detail, understanding how both old and new versions of your application will interact with the database during each phase.

• Finally, develop a rollback strategy for every single step. Think of it as your safety net - you need to know exactly what to do if things go sideways.

Well, even with perfect planning, things can still go wrong during deployment. This is one of those skills that comes with experience. In the beginning, you will likely stub your toe a few times - it is almost a rite of passage. But with each deployment, each mistake, and each recovery, you will build up the knowledge that will help you prevent such issues.

In one of my previous posts, I described this problem in detail (based on a real-world example):

UI issues that were not caught by automation

One of the best lessons I learned while working with continuous deployments was to accept artifacts that can occur in production. What do I mean by an artifact? For example, we can accept that while the key business process works fine (validated by our automated tests), there is a chance that something minor might not work as expected.

Let me explain.

Imagine that inside your application there is a modal window that is part of a business-critical process. This window contains some kind of a form, and additionally two buttons - one to cancel, and another one to submit.

After one of your CSS changes, someone spots in the production environment that buttons are outside of the modal, floating somewhere around:

How was that possible? While your automated tests can verify your critical business process perfectly well, they might miss these kinds of visual details. Sure, your tests can confirm that buttons exist, find them, and execute the action, but they won't catch if a button suddenly appears in the wrong spot on the page. It is a blind spot in automation that you need to keep in mind when setting up continuous deployment. But here is the point: you can quickly react and deploy the new version (I prefer it over the rollback, but you can also roll it back) within minutes or hours, thanks to the automation that you have.

Failures caused by updating libs

Library updates are an integral part of development life. Whether they are internal or third-party. The trigger could be anything from needing a new feature to avoiding a security vulnerability. But regardless of why you are updating, it is the aftermath that can give you a real headache.

Take this common scenario. Everything compiles perfectly, all tests pass with green color, but then you hit runtime and... surprise!

It is similar to the modal example earlier - you might update an image library and while your automated tests happily verify that the image tags exist in the HTML, they won't catch that the images themselves are rendering incorrectly.

This is a relatively simple example, but it illustrates a broader point. Good observability tools (looking at you, Sentry!) can help you catch these issues before your users do, but it is still a classic mistake that you need to watch out for.

Summary

Continuous deployment is a powerful practice, but it is important to approach it with eyes wide open. While the examples I have shared might seem discouraging, they are part of the learning process that every team goes through. The key isn't to achieve perfection - it is to learn from each incident and maintain the ability to respond quickly when things go wrong. And remember, what matters most is finding the rhythm that works for your team, your product, and mainly your customers.

If you are interested in a general overview (where these mistakes are one of the topics), feel free to watch a video from one of my talks called “Oops, I deployed it again: a survivor’s guide to continuous deployment”:

This year, I am moving the annual list to my newsletter, focusing exclusively on 2024's outstanding books, talks, and other resources. It has been a remarkable year for architectural knowledge, with excellent publications and insights worth sharing.

I will focus mainly on software architecture, but also on related topics. Let's start with books.

Books

Writing "Master Software Architecture" dominated my 2024, which meant less technical reading than usual. The book's demanding creation process consumed most of my energy and focus until August. Once I finished the manuscript, I dove back into reading and discovered several exceptional titles published this year (in random order):

1. Platform Strategy by Gregor Hohpe

2. Architecture Modernization by Nick Tune

3. Understanding Eventsourcing by Martin Dilger

4. Balancing Coupling in Software Design by Vladik Khononov

5. The Accidental CIO by Scott Millett

Talks

Next, I would like to share my curated selection of the most impactful architecture talks from 2024. I have arranged these without any particular ranking to focus on their individual merits:

1. So You Want to Build An Event Driven System? by James Eastham

2. An Introduction to Residuality Theory by Barry O’Reilly

3. Let's build the worst Event Sourcing system! by Oskar Dudycz

4. Architects Aren’t the Smartest People in the Room by Gregor Hohpe

5. Design more decoupled services with one weird trick by Udi Dahan

Articles

These articles and blog posts hit home for me in 2024:

1. Deduplication in Distributed Systems: Myths, Realities, and Practical Solutions by Oskar Dudycz

2. Clean Architecture: The Missing Chapter by Milan Jovanović

3. The biggest-ever global outage: lessons for software engineers by Gergely Orosz

4. The Documentation Tradeoff by Kent Beck

5. 3 Surprising lessons you can adopt from Extreme Programming by Denis Čahuk

Additionally, I invite you to read one article from my newsletter which was the most popular one in 2024. It shows you how to frame technical decisions in business language that resonates with stakeholders:

Repos

Unfortunately, I haven’t found any interesting repo in 2024 that would show you some architectural concerns and explain them with real-world examples. However, two existing repos remain invaluable for anyone serious about domain-driven design and system modularization:

1. Modular Monolith with DDD (.NET 8) by Kamil Grzybek

2. Evolutionary Architecture by Example (.NET 9) by Kamil Bączek and Maciej Jedrzejewski

Summary

Looking back at 2024, I can't help but feel optimistic about where software architecture is heading. More teams are embracing fundamentals, and thoughtfully considering system coupling - changes I witness daily in my consulting work. The resources I have shared capture this momentum perfectly. I can't wait to hear which ones resonated with you and what you will build next.

Keep building amazing things, and see you next year with more architectural adventures!

Your app will probably get complex (or at least complicated), even if it doesn't get enormous traction. Like in real life - you start with a simple house, but then you add a garage, a garden, maybe a swimming pool. Before you know it, you have got a whole neighborhood.

Subscribe now

The same happens with code. Maybe you start with a basic user login. Then you add password reset. Then social media login. Then two-factor auth. Then single-sign-on. It gets complicated.

Your business will also change - it always does. Take an insurance company. They start with car insurance: checking driving history, car value, and accident risk. Simple enough. Then they add home insurance. Now you need to handle property values, natural disaster risks, and security systems. Different rules, different checks. Next comes life insurance. Suddenly you are dealing with health records, age calculations, and beneficiary management.

Each type seems similar on the surface - it is all insurance, right? But the rules are completely different. Your code starts filling up with "if this is car insurance, check X, but if it is home insurance, check Y, and if it is life insurance, check Z.” Before you know it, you are drowning in conditional statements.

The infrastructure side also brings its own complexity. Imagine a startup app - one web server, one database. Works great at first. Then traffic grows. The app gets slow. Adding a cache helps with speed. A message broker handles the communication. One database can't keep up, so you add replicas. The web server maxes out, forcing you to add more servers and a load balancer. And so on. Suddenly your simple system turned into a distributed one. Now you are facing node coordination, data syncing across databases, and network failures. What used to be "it works on my machine" becomes "which of these 20 machines is causing the problem?"

Complexity builds up everywhere - new features, business rules, servers, databases. And the more complex your system gets, the harder it becomes to maintain it.

How can you address such problems?

In the case of infrastructure, keep an eye on your system from the start. Add monitoring tools early. When you add new pieces, make sure you can see how they are performing. Also, try to automate as much of your infrastructure as possible, already from the start. Write code to handle server setup, configuration, and deployment. That way, when your system grows from 2 components to 20, you won't lose track of what is running where or how it all fits together.

Without good automation and monitoring, you will get overwhelmed trying to manage everything by hand. One small mistake in server configuration, one forgotten setting, and your whole system can break in ways that take hours to debug.

As your code grows, simple entity-level logic isn't enough anymore. At first, putting behavior directly in entities worked fine. But when these need to work together, it might be time for another solution.

What you can do is create an aggregate that watches over related entities. Think of aggregates as rule enforcers - they keep all operations consistent and prevent unauthorized changes. Example? A Prescription aggregate makes sure only the prescribing doctor can cancel their prescriptions. Or a BindingContract aggregate allows (or disallows) to sign an Annex.

As your business changes, update your architecture to match. Keep refining the system’s boundaries - split them when they grow too big, merge them when it makes sense, and drop them when they are no longer needed. Here is an example coming from my book:

Private medical clinics that use our software also want to offer telemedicine. We extend the Patient Treatment bounded context to accommodate this change. It looks like it fits there – after all, it is just another treatment method.

However, with telemedicine, the patient does not need to come for an appointment, and there is no physical examination. Additionally, no follow-up appointment will be planned. We start wondering if this is a good idea, but the decision is to leave it as it is.

Three months later, clinics decide to offer specialized treatment. When a patient needs a consultation with an external specialist, they have to call the specialist and book an appointment.

Once a month, all specialists collaborating with the clinic send their invoices. Then, the clinic sends another invoice to the patient. As this is another treatment method, you decide to extend the Patient Treatment again, despite the process being entirely different from the initial state.

Problems arise. Maintenance requires increasing effort. More than one development team is needed. Too many people are working in the same area, and communication between them begins to fail. Terms start to be used in different contexts— Doctor refers to either an internal doctor or an external specialist. The former is on a contract of employment with the clinic, while the latter sends invoices to the clinic.

Ultimately, Patient Treatment becomes enormous, and you spot that the scope, rules, terms, and behaviors are completely different from what was initially defined.

The wise decision is to split it now into several new bounded contexts:

• Telemedicine. This covers remote patient consultations and treatment. It includes virtual visits, digital communication, and remote monitoring of patients.

• On-site Treatment. This represents the initial process of patient treatment where the patient visits the clinic, is examined, agrees to the treatment plan, and starts the treatment.

• Specialized Treatment. This handles interactions with external specialists and ensures that the collaboration with them is streamlined and distinct from the internal operations

Managing complexity is an ongoing challenge, not a one-time fix. As your system evolves, keep watching for signs that your architecture needs to adapt. Whether it is infrastructure growing beyond your ability to manage it manually, entities that need new ways to enforce rules, or bounded contexts that no longer fit their original purpose - be ready to make changes.

Last thing to remember: what worked perfectly six months ago might need a complete redesign today, and that is perfectly normal in the life of a growing system.

Think about concert ticket sales. Let’s take Taylor Swift concerts as an example. Or if we hop in a time machine, imagine the chaos of The Beatles fans in 1964 or Queen enthusiasts in 1982 rushing to buy tickets at once. In these scenarios, certain parts of your ticketing application - like the ticket catalog, checkout, and payments modules - get slammed with traffic. However, other modules sit mostly idle.

Subscribe now

This is where a modular monolith can start showing its limitations. Sure, you can scale up by adding more instances, but there is a catch: spinning up new instances takes precious time, and you are forced to scale everything, even the parts that don't need it.

Plus, some modules in your application might need frequent updates while others remain relatively stable. Yet with a modular monolith, every small change in one module means redeploying the entire application - even the modules that haven't changed.

When your application's growing pains start affecting both your team and customers through slower performance and frustrated users, it is time to take action. Let's say your ticket catalog module becomes the bottleneck - from time to time fans can't even browse available events.

What could be a solution? Extract the problematic module from your modular monolith and turn it into its own independent deployment unit. This could be a microservice, a nanoservice, or any other self-contained deployment unit. By separating it, you can scale and modify it independently from the rest of your application (of course, if there is no tight coupling between them).

Once you have separated the ticket catalog, you gain precise control. Need to handle a surge of fans browsing concert tickets? Scale up just the catalog service. Making updates to how tickets are displayed? Deploy changes to the catalog alone - the rest of your application keeps running untouched.

This separation comes with a trade-off: as your system becomes a distributed one, your services now need to talk across network boundaries which means higher latency and exposure to network errors and partitions.

You can no longer rely on simple internal communication methods like direct references, facades, or gateways that work when everything lives in the same application.

Instead, you have two main options:

1. Set up a message broker like RabbitMQ to handle communication between your ticket catalog and the main application. This is usually the recommended approach, as it keeps your services loosely coupled and more resilient.

2. Have your main application call the ticket catalog's public API (like REST endpoints). While simpler to implement initially, this creates a direct dependency between services and might make your system more brittle.

Keep in mind that not every application will face these challenges. Many systems will run perfectly fine without ever needing to handle massive user loads. And even if your application does experience significant growth, scaling your modular monolith horizontally might still be the simplest and most effective solution.

Don't rush to break apart your application into a distributed system just because it is a trending approach - make architectural decisions based on real needs, not hypothetical scenarios. The goal is to find the sweet spot between scalability and complexity that matches your actual requirements.

Subscribe now

At some point, we need to think about other aspect of our system - like how easy it is to maintain. Maintainability is the second step in our evolutionary architecture approach.

When you start simple, your system naturally becomes easier to maintain. You don't have a bunch of external components like cache or data streaming tools to worry about. Fewer moving parts means fewer things can break, which makes maintenance much smoother. Though let's be real - if your code is a spaghetti, even the simplest system will be a headache to maintain ;)

The tricky thing about keeping the system simple is that your early decisions can come back to bite you and your team as the system evolves. Every system faces different growing pains depending on its context.

When certain parts of your code start expanding faster than others, your simple design might not scale well with them. Some modules turn out to be way more complicated than you first thought. Plus, as your organization grows and you want different teams working independently, those early simple choices might actually get in the way, negatively affecting maintainability.

Example? Imagine this scenario: You start with a simple setup - one assembly and four developers. Life is good. When someone needs to change something in a module (represented by a folder in the assembly), the team huddles up, discusses it, and makes it happen. Clean and straightforward.

But then your system grows. Now there are three teams, each owning different modules. And here is where that simple structure starts causing headaches. Every time one team wants to update a third-party package - even for their own module - they have to:

1. Notify other teams

2. Wait for them to review and approve

What was once a quick decision now turns into a slow, multi-team coordination flow. Your simple, single-assembly approach has become a bottleneck that is actually making things more complicated, not less. That is a classic example of when simplicity from the past can handcuff you in the present.

Code changes become a real headache too. With three teams of four developers each, you have twelve people all trying to push code into the same assembly throughout the day. That means constant merge conflicts and developers wasting time resolving them instead of building features. What used to be a smooth workflow with a small team turned into a daily battle with Git.

There is no magic solution to these growing pains - you need to find what works best for your situation. In our example above, one approach would be to break each module into its own separate assembly. But this is just one way to go - the key is to choose what makes sense for your specific needs.

How do you spot a maintenance problem? Simple: your team starts feeling the pain. And how do you know you have fixed it? Even simpler: that pain disappears and your team can work smoothly again. No need for complex metrics or fancy formulas here - just good old common sense will tell you everything you need to know.

How do you deal with maintaining the growing system?

Two years ago, Kamil Bączek and I created a repository demonstrating the evolution of a Fitness Studio application. We structured it around four key evolutionary steps we identified.

Each step represents a distinct phase in your application's maturity. This series will break down all the steps so you can understand them better.

Today we will focus on the first one - simplicity.

When starting a new app, we often get excited and want to throw in every cool tech we have heard about - Kubernetes, Kafka, Redis, microservices, you name it. And it is natural - we are developers, and we love trying new things!

Here is the thing - we often get caught up copying what big companies like Netflix or Amazon are doing. But that is a trap. Their problems and scale are nothing like what most of us are building. Their systems are solving totally different challenges, dealing with traffic levels our apps may never see.

Subscribe now

When we overcomplicate things from the start, we create a mess. Systems end up with too many moving parts talking to each other. New team members struggle to understand what is going on. Bugs become a nightmare to track down. And don't even get me started on the costs - they spiral out of control. All because we let our tech dreams run wild instead of keeping things simple.

You know what is funny? This keeps happening even though we are smart people. So what is the deal? From what I have observed, it is not about being smart - it is about wisdom. And that wisdom? You only get it from years of building different systems and, yeah, screwing up along the way. Those face-palm moments when things go wrong? They are actually our best teachers.

We spend years learning this hard truth: there is no one-size-fits-all architecture that works for everyone. What works depends on your specific situation - your team's skills, your company's setup, and what your business needs. People keep talking about "context" because it really is everything.

Context is king - and they are right.

In this first step - Simplicity - we are not reinventing the wheel. The goal is dead simple: build the most straightforward solution that works right now.

Here is the catch: we should stick to keeping things simple no matter how far along we are. But it is trickiest at the start because that is when we have to make the most decisions. And guess what? That is exactly when we know the least about what we are building and how it will be used.

This problem is known and is called the Project Paradox.

The graph makes perfect sense - by the time we actually understand things well, most of the big decisions are already behind us. Ironic, right?

That is why starting super simple is like a cheat code. We push the big decisions into the future, when we will actually know enough to make smart choices. Instead of guessing early, we learn as we go.

OK, but what does it mean to start simple?

Think about starting with a modular monolith instead of microservices. You dodge all those distributed system headaches - no network failures, no latency issues, no need for retry logic. Everything runs in one process, so modules just talk to each other directly (by reference, gateway, facade) or use events within the in-memory queue.

Yeah, here is a spicy one - consider using initially an in-memory queue instead of something external like RabbitMQ. Sure, you might lose some messages if the system crashes, but maybe that is okay for now. You are trading some reliability for much simpler maintenance. As always, in such cases use your common sense.

Or take databases. Instead of giving each module its own database (physical split), use database schemas (logical split) to keep things separate. So, each module will have its own schema. It is simpler but still keeps your data organized.

Instead of jumping straight to Kubernetes, start with a simple deployment using e.g. Azure App Service, or AWS Elastic Beanstalk. You will spend way less time on infrastructure and can focus on what your app actually needs to do.

Skip the fancy caching system at first. Instead of setting up Redis right away, leverage the power of your database engine to a maximum, or in the simplest scenario use your application’s memory cache (if the application runs on a single instance).

And so on for all areas of your application.

Think of every change like it is coming out of your own pocket - you are paying for the servers, maintenance, all of it. Once you start thinking this way, you will get better at spotting unnecessary complexity. It is like developing a sixth sense for what is really needed versus what is just cool to have.

Trust me, it will change how you look at every decision.

Curious about seeing this in action? Check out our Evolutionary Architecture by Example repository. We also have a Discord channel where you can ask questions and join the discussion.

What do you think about such an approach?

It may seem difficult to tell the difference between the two since they both check how your application performs against the traffic that comes to it. The key difference is that load testing checks how your application performs under expected traffic (with some overhead) for a given period, while stress testing has a different mission: it pushes your application to its limits to see how it behaves under extreme conditions, such as when traffic suddenly spikes to double its usual volume.

This helps you find weak spots and confirm if your application can handle expected user spikes - think of big moments like the NBA Finals or Black Friday sales.

It also reveals when your current setup might need an upgrade or a complete overhaul by showing where and when your application starts to break under pressure.

By monitoring your application during stress tests, you will see how quickly it scales and what costs you might face over time. It will help you prevent nasty surprises in production - like your app crashing under heavy traffic or your cloud bill skyrocketing unexpectedly. The best part? You can do all this testing in a controlled environment.

There is also no need to reinvent the wheel - you can reuse everything you have already set up for load testing, including your test scenarios and known bottlenecks. And just like load testing, where you run your stress tests depends on your specific context and your software development process. It can be run on the canary candidate, blue or green environment, UAT, staging, or wherever.

But here is an important difference: timing. You would not run your stress tests as often as load tests. They are more expensive and they test extreme situations that don't happen every day. To keep things practical, I suggest running stress tests in the following situations:

1. Before releasing the MVP. This is the time to discover the true limitations of your application. If your product takes off quickly, you will know in advance where your application's weaknesses are. This way you can decide what to do - accept it or fix it (both options are fine, of course, depending on your context).

2. Before big traffic events like Black Friday. We have all been there - refreshing a ticket website that is struggling to keep up with thousands of customers. Your users deserve better than that frustrating experience.

3. After launching a high-impact feature that you expect will be heavily used. Think about new social media features or the game-changing functionality your users have been asking for.

4. Before entering a new market. Whether you are expanding geographically (e.g., from Europe to Asia), targeting a new customer segment, or entering a new industry, you need to know if your infrastructure can handle different traffic patterns. Each market can bring its own challenges and different peak usage times.

5. On a regular schedule that makes sense for your product - maybe monthly, quarterly, or a few times per year. There is no one-size-fits-all approach here; watch your patterns and adjust your testing frequency accordingly.

Okay, now you know when it can be done. Now you may be wondering how to do it. What tool to use? One of my favorite ways to test the performance of my applications is to use Grafana k6 (no paid advertising, this is something I use and like).

The setup is not that complicated and the UX is really good.

Of course, it doesn’t matter whether you choose k6 or another testing tool (e.g., JMeter). The key is to start implementing stress tests strategically and systematically.

Remember, stress testing is not just another checkbox in your testing routine - it is your early warning system, and I like to call it an “ass-saver”. While it might seem like extra work, it is far better to discover your application's breaking point in a controlled environment than during a crucial event with real users.

Now, go forth and stress test - but don't stress about it! ;)

Then, we release it and observe the growing number of users. We monitor how the application works, and suddenly it stops working due to too much traffic. We are stressed as now we have to react fast to this situation to make the application available.

Subscribe now

Instead, you could perform load and stress tests before you even think about releasing the application to the public, and thanks to it you know the numbers up in front. Today, I would like to focus on load testing which helps you check how your application performs under defined traffic for a given period.

Let’s assume you have developed an MVP that hasn’t been released yet. Based on your analysis, you expect around 50,000 concurrent users in the first month.

It is much better to discover problems now than when real users are hitting your system. No one wants to be firefighting issues while customers are complaining and executives are breathing down your neck. Load testing lets you find and fix bottlenecks before they become real problems.

What should you test? Focus on what matters most.

Think about it - users will not constantly update their profile picture or reset passwords. But they will hammer certain features hard. If you are running a ticketing platform, the checkout flow will get slammed. Payment processing might become your bottleneck. User default address updates? Not so much.

Put pressure where it counts. Identify your high-traffic features and load test them properly. Don't waste time load-testing everything equally - it is not how your app will be used in real life.

First, figure out which parts of your app need load testing. Focus on features you expect users to use the most. Sounds simple, right? Well, it depends.

If your app is not live yet, you are making educated guesses. Sometimes these guesses are good, sometimes they are shots in the dark.

Let me give you an example:

• In a large hardware company, you might know exactly what is coming: 25,000 devices syncing their data exactly at 3 pm every day. That is a clear target to test for.

• It would be trickier in a startup. Your users might surprise you by using features you didn't expect, or your whole business model might pivot next month and this will completely change your expected numbers.

If you already have a live application, check your analytics. The data will show you exactly where users are piling up.

The key is being realistic about how much you can predict. Sometimes you know exactly what is coming. Other times, you are making your best guess and need to stay flexible.

Once you have spotted your high-traffic areas, you will need a solid test plan. Here is what should be in it:

• The scenarios you want to test. Thanks to the discovery, you have a list of areas you want to subject to load testing. Now, you need to develop specific scenarios for these areas. These scenarios will outline the actions and conditions you want to test. I recommend preparing scenarios that imitate the regular user flow. For example, in the case of buying tickets, your test should mirror the user’s journey from accessing the home page, searching for the event, opening the event page, selecting the number of tickets, proceeding to the checkout page, and completing the payment.

• The number of concurrent users. It defines how many users you want to imitate to generate the expected traffic. This number may vary between different areas; for example, one area might typically handle 25,000 concurrent users while another might handle 100,000. I also recommend adding 20-30% for each load test because it gives you a certain reserve in case the traffic increases fast in the production.

• The time limitation to perform load tests. Load tests should not run indefinitely, as this can incur costs and delay feedback. It is advisable to set a time limit, such as running each load test for approximately 30 seconds, with all tests completed within 10-15 minutes.

One common pitfall is assuming that users will follow a predictable pattern. For example, a 70% discount on a popular item may not be spread evenly over 15 minutes for 15,000 users (1,000 users per minute). Instead, you might see most of the users in the first few seconds. Be cautious of such scenarios!

The last aspect to consider is where and when to run load tests. This is a nuanced question with no single answer; it depends on your specific context.

Load testing should not be a one-time action but a repeatable process. Ideally, it should be conducted for every change made to the production code. However, this may not always be feasible (as discussed in previous steps). Therefore, there are various approaches to scheduling load tests.

If you deploy the application multiple times per day (like in continuous deployment), it makes sense to run load tests each time the commit is pushed to production. This way, load tests will be a part of your deployment pipeline.

Some companies can't just push code whenever they want. Maybe you are dealing with banking software or medical systems - places where every release needs serious vetting. In these cases, your load tests happen before your scheduled releases - think quarterly or bi-annual deployments. You will run them in staging or UAT environments, giving yourself plenty of time to catch and fix issues before the big release day.

It is less frequent than continuous testing, but that is fine - it matches how you actually ship code. The key is having a testing rhythm that fits your release cycle.

How do you handle load tests in your application?

Join 100,000 architects and engineers building apps and transforming workflows with Budibase.

That was it. The moment he used technical terms like "modular monolith," their eyes rolled over. His chance to get support for changes vanished in seconds.

The thing you need to be aware of

Most often - in about 90% of cases from my experience - business people don't care about technical terms like cloud platforms, databases, microservices, or system architecture. What catches their attention are numbers that directly matter to the business:

• How much can we reduce our monthly operating costs?

• Can we cut customer delivery time from 2 days to 2 hours?

• How many new customers can we handle without hiring more staff?

• What is the return on investment, and how soon will we see it?

• How much revenue are we losing due to current system limitations?

These questions about costs, speed, and business growth are what business leaders care about. How we achieve it - whether through Kubernetes, microservices, or any other technical solution - is why they hired us - software engineers - in the first place.

Think of it like hiring a builder to renovate your house. You care about:

• How much will it cost?

• When will it be finished?

• Will it increase your property value?

You don't need to know about the specific brand of power tools, types of screws, or construction techniques. You trust the builder's expertise to choose the right tools and methods. That is their job.

Selling outcomes, not technicalities

Having all of the above in your mind, always try to find the outcome of your change and sell it. Here are some examples:

Scenario 1 - The current monthly operating costs of the cloud are $100,000

Don't get caught in the trap of explaining technical details about switching services and databases. Instead, focus on the bottom line: "Our solution can cut operating costs in half, saving $50,000 every month."

Now comes the most important part - the investment cost. Let's look at two scenarios:

If the migration costs $1 million, you will need 20 months just to break even ($50,000 × 20 months = $1 million). For an application that is only planned to run for 1.5 years, this would be a poor investment.

But change the numbers, and the story changes dramatically. If migration costs only $50,000, or if your application will run for 10 years, suddenly you are looking at substantial long-term savings.

Scenario 2 - Our customers complain about delivery time

When proposing a solution to speed up delivery, many engineers would dive into technical details, listing all the components and systems we need to change. This is a common mistake.

Instead, focus on the business impact: We can reduce delivery time by at least 25%. In real terms, this means cutting down from 4 days to 3 days per delivery. The implementation will cost between $10,000 and $30,000.

This kind of communication gives business leaders exactly what they need - a clear picture of improvement (X% faster delivery) and cost (Y dollars). Even if you can't provide exact costs (and let's be honest, who can? 😄), having a rough range - whether it is thousands, tens of thousands, or hundreds of thousands - gives them enough information to make a business decision.

Scenario 3 - One of the components will reach the end of support in May next year

Avoid the common technical trap of discussing security vulnerabilities like supply chain attacks. These terms mean little to business leaders and don't convey urgency.

Instead, focus on the business risk: "We must complete this migration by January. After that date, we lose official support, which creates a serious risk of customer data theft and exposure."

This message hits home because it translates a technical deadline into real business consequences. Data breaches mean lawsuits, damaged reputation, lost customers, and potential regulatory fines. No business leader wants to explain to customers why their data was compromised because we missed a critical deadline.

Here are a few other examples presented as one-liners:

1. “We need to implement proper caching mechanisms” → “We can reduce customer wait times from 3 seconds to under 1 second”

2. “Our system needs horizontal scaling and load balancing” → “We can handle Black Friday sales peaks without website crashes, preventing $100K in lost sales”

3. “We should migrate to a newer version of the payment gateway API” → “We are losing $5,000 monthly in declined transactions that newer payment systems would approve”

4. “Our logging and monitoring infrastructure needs improvement” → “We can detect and fix problems before customers notice them, reducing support tickets by 30%”

5. “The authentication system needs to be refactored” → “We can cut customer login time from 7 to 1 second, reducing shopping cart abandonment rate by 15%”

As engineers, we are passionate about our solutions. We see the technical beauty and understand why upgrading this database or refactoring that code is "obviously" important. But when we talk in technical terms, we speak a foreign language to business stakeholders. Then we get frustrated when they don't see the "obvious" benefits. And they get frustrated because they can't understand the jargon. A lose-lose situation.

Don’t sell refactoring

When it comes to refactoring, less talk is often better. Instead of explicitly asking for "refactoring time," simply include it in your regular feature development estimates. When you say "This feature will be delivered in this sprint", that time already includes necessary code improvements.

For larger refactoring efforts (like replacing major components), don't sell it as refactoring at all. Find the business value and lead with that. “We found an issue in our application and have an option to get rid of it. If we do it:”

• "This change will cut our response times in half"

• "We can reduce error rates by 30%"

• "This will allow us to add new features twice as fast"

• "We will cut our monthly cloud costs by 25%"

Can you see how different this communication is? No explicit mention of “refactoring”. It is the same work, but entirely different framing. You are not hiding the refactoring - you are simply focusing on what matters to the business. That is it.

What is your biggest challenge when explaining technical solutions to non-technical people?

Budibase saves architects and engineers 100s of hours building apps and automating workflows securely.

Subscribe now

First issue: When architects sit far from dev teams, they are clueless about real problems. They don't code with the team, so they have no idea what headaches their designs cause in day-to-day work. You need to get your hands dirty to know if something works.

Second: When architects just draw diagrams all day, they get rusty. They lose touch with tools, don't keep up with new programming languages, and basically start to live in their own bubble. Out of touch with tech, stuck in their old ways, and more focused on theory than what actually works.

Third: This setup kills developer growth. When all architecture decisions come from above, we stop caring about system design. We turn into code monkeys, mindlessly producing features without thinking about the bigger picture, and the consequences it has for our business.

Oh man, I had no clue back then how much I would dislike this kind of setup in the future and how hard I would fight it at every company I worked at. But damn, it was worth every battle.

What could it look like? My take as an experienced architect:

The whole development team owns the architecture of their code - period. Whether they are working on a small part (like payments or scheduling) or the whole app if it is smaller.

Don't care if an idea comes from a junior or senior dev. Everyone gets an equal say. But here is the key: the whole team needs to discuss and agree on decisions. No room for egos or "I am the boss" attitudes here. In one of my previous articles, I described how to organize the work within such a team and make meaningful and democratic decisions using a developer carousel.

Some people will argue: "That only works for small companies." BS. While yes, changing from ivory towers takes time (humans hate changing habits, so it is a pain, I agree), it is totally doable if you take it step by step. I have worked at tiny companies and large-scale organizations - this shift can work anywhere but sometimes it will require tons of politics.

When multiple teams work on a large system, one great way to share knowledge and keep architecture in line with business needs is setting up an "architecture guild." As Jakub Nabrdalik puts it:

How the guild works

The guild meets regularly once per 2 weeks, but also has meetings ad-hoc to address urgent issues when they arise. When the guild meets, it discusses the problems and work required, invites all the relevant people (outside of the guild), schedule the necessary research, creates an RFC document to gather all possible input from people with the knowledge on the issue matter, chooses the person responsible for getting the decision done.

Who is responsible

Every 2 weeks one person from the guild is chosen as an acting Speaker of the guild. That person holds personal responsibility, for making sure, that the guild makes the decision in efficient manner. For every issue discussed by the guild, a person responsible will be chosen. If there are no volunteers, the Speaker of the guild is responsible. The Speaker is also on an on-duty of the architecture guild, where she is responsible for answering all the questions from outside of the guild.

Here is my take on organizing a guild: Just read Jakub's repo. The first time I set up a guild, I basically copied his approach word-for-word. Then adjusted it with the next iterations to our needs. Now whenever someone asks me how to do it, I just send them his guide. Important note from me: Anyone can join the guild, no matter of experience. The only rule? You need to actively participate. That's it.

When you let the whole team make architectural decisions, good things happen. No more knowledge trapped with just a few people, everyone owns the architecture, developers grow way faster, and honestly - it is just way more fun to work in this kind of environment.

What do you think of a setup where the entire software development team is involved in architectural decisions? How does it look in your team?

Several factors can lead to unexpected costs. These include inadequate preparation for denial of service attacks (DoS & DDoS), excessive logging without considering the need for it, massive use of expensive storage tiers, and implementing auto-scaling without limits.

I cover all of these topics at conferences in my talk "What Every Software Architect Should Know About Infrastructure". It is time to describe them here as well.

Subscribe now

Being prepared for DoS & DDoS

This year, around May or June (I can't remember exactly), I saw a thread on Reddit where someone described their problematic situation. In short, they received a $104k bill for hosting their static website.

You might ask, "What? Over $100k for a static site? That is insane." Yes, it is. The reason for such an amount was a denial of service attack. In the starter plan, the hosting provider charges $55 per 100 GB of bandwidth above the first 100 GB, which is free.

There were different opinions about this situation. Some people said that it was the author's fault and that he should have read and analyzed the pricing information first, which explicitly stated that the provider charges $55 per 100 GB. Other opinions were that the provider should have some built-in mechanisms to defend against DDoS attacks in such cases. I think both sides are right to a certain extent, but this is not the time to find the guilty. Instead, let's look at what can be done to avoid such a situation.

Denial of service attacks usually occur in one of three layers: 7 (application), 4 (transportation), and 3 (network).

The first step you can take is to minimize potential points of attack. The math is simple - the fewer points, the better.

Next, you can use out-of-the-box solutions from the cloud providers. In Azure, this is Azure Frontdoor, and in AWS, it is AWS Shield. Another option is to use third parties like Cloudflare. I really like the latter because it offers seamless integration with the aforementioned clouds + it's pretty cheap.

Mistakes that cost a lot

Another example of exploding costs was the Cara app. Here is the story (according to Gergely Orosz):

In short, the Cara app used serverless on Vercel and it worked perfectly. The problem was that at some point the app went viral and incurred extreme costs ($98k to run it for a few days).

I think this is a good lesson for anyone building a public-facing application that has the potential to go viral, and when I say be ready, I mean at least one of the following.

Have enough money ready

Think of this as having a safety net:

• Secure investment funding (venture capital, angel investors, or personal capital)

• Be prepared for significant infrastructure costs

• Scale infrastructure dynamically based on demand

Advantage: Guaranteed service availability for all users

Challenge: Requires money (sometimes a lot of money)

Controlled scaling with limits

With this approach, you need to implement scaling boundaries:

• Set clear infrastructure limits (e.g., 2-3 server instances)

• Accept that some users may experience service unavailability during peak times

• Communicate limitations transparently to users

Advantage: Predictable costs and manageable infrastructure

Challenge: Potential user dissatisfaction during high-demand periods

Cost-optimized infrastructure from day one

Here, you have to focus on optimization from the start of application development:

• Optimize application performance and resource usage

• Aim for significantly reduced operational costs (e.g., 10% of unoptimized costs)

• Implement efficient caching strategies

• Choose cost-effective service providers and technologies

Advantage: Balance between cost and performance

Challenge: Requires a lot of initial optimization efforts (but you will benefit a lot from it)

The hidden costs of storage

One of the most common problems I see when it comes to high infrastructure costs is data storage. I can't count the number of times I have seen files stored in the hot tier of the cloud while being accessed extremely infrequently.

At first glance, when a cloud provider charges $0.023 per GB for a hot tier, it might seem negligible. For applications storing just a few hundred megabytes, the monthly cost is indeed minimal—around two cents. However, the real challenge emerges when your application's storage needs grow exponentially.

Consider building a social media application. Let's break down this scenario:

• User base: 10,000,000 users

• Storage allowance: 100 images per user

• Maximum image size: 5 MB

Doing the math:

10,000,000 users × 100 images × 5 MB = 5 PB = $115k per month

Shocking, isn't it? This shows why we can't be misled by looking at small-scale costs. What seems like pennies can quickly escalate to six figures when operating at scale.

High costs generated by logs

As a software developer, I know firsthand that we developers have a habit: we love to log everything. And when I say everything, I really mean everything!

Let me share an example that shows just how expensive this can get. In one project I was involved in, the forecasted logging cost was about $10k per month. But guess what? The real bill ended up being more than $100k per month! That's ten times more than was planned for.

What was the problem? We discovered the team was logging tons of information that nobody ever looked at or used.

The solution was simple but effective: they cut down on unnecessary logs and in the end, switched to a different logging platform. This meant only keeping the logs that actually helped us monitor and fix issues in our system. Sometimes less really is more – especially when it comes to your cloud bill.

TL;DR

Unexpected infrastructure costs can explode due to the following factors:

1. DDoS attacks. A static website got a $104k bill due to unprotected bandwidth charges.

2. Viral success without preparation. The Cara team faced a $98k bill for running a viral application for several days.

3. Hot storage misuse. What seems cheap ($0.023/GB) can scale to $115k/month for a social media app with 10M users.

4. Excessive logging. One project's logging costs jumped from $10k to $100k/month due to logging unnecessary data.

Solutions include:

• Using DDoS protection (Cloudflare, AWS Shield, Azure Frontdoor)

• Having funding ready or implementing controlled scaling

• Optimizing infrastructure from day one

• Using appropriate storage tiers

• Logging only necessary information

What are your thoughts on exploding costs? Have you ever faced such a situation in your project/product?