Lmst

#ArchitectureWeekly

I've been facilitating the #EventStorming sessions for years now, and something keeps catching my attention.

While teams naturally focus on mapping out those orange event sticky notes (the backbone of any EventStorming session), they often underestimate the power of two critical elements: Hot Spots and Notes.

What I value most about Hot Spots and Notes isn't just how they improve workshops - it's how they change team culture around uncertainty.

In technical discussions, we often feel pressure to know everything immediately.

Hot Spots create permission to say, "I don't know yet" while still making progress. They transform uncertainties from conversation-killers into clearly defined next steps.

I've seen teams evolve from hiding what they don't know to actively hunting for uncertainties as valuable information. Questions become assets rather than liabilities.

If you're incorporating EventStorming into your toolkit, don't underestimate these powerful elements. They might not get as much attention as domain events, but in my experience, they often separate a productive modelling session from a frustrating stalemate.

Sounds like #ArchitectureWeekly just passed 10 000 subscribers. Nice! 🤟😎

Have you heard a surgeon say: "I won't sterilise my tools, as the patient won't let me"?

I haven't, but I have heard multiple times: "Business won't let us add unit tests."

As this grinds my gears, I decided to write my take on why we tell those lies to ourselves. I think that it's more about us avoiding accountability and dodging our duties than about mischievous business people.

What's your take on that?

Object-oriented or relational? Why not both?

For many years, we tried to fit the business data into a normalised table structure. We used Object-Relational Mappers, which was a constant battle on how to map unfitting models.

Then document databases like MongoDB came along and got traffic.

Still, many people wanted guarantees they had in relational databases, they also wanted to reuse muscle memory related to operations and other tooling.

Now we have the choice as we have #JSONB data type implemented by #PostgreSQL and then by MySQL, SQLite.

The B in JSONB stands for binary. It looks like a JSON, it quacks like a JSON, but it's not JSON. And thanks to that, it's powerful.

When you're storing JSON data in JSONB, it's parsed, tokenised, and stored in a tree-like structure. Types are preserved, and a hierarchical structure is also preserved, and thanks to that, you can index it and efficiently query it.

I'm super happy that in recent years, I have had the opportunity to use Postgresql and JSONB, first in Marten and now in Pongo. I didn't look back. JSONB has its cons, but for most typical line-of-business applications, they're negligible.

I finally wrote an intro in #ArchitectureWeekly about how JSONB works, check it, tell me how you liked it and share with your friends!

And most importantly, play with it on your own 😊

https://www.architecture-weekly.com/p/postgresql-jsonb-powerful-storage

The pendulum swung back! Now, the "modular monolith first" is the best advice. But is it?

Every few years, our industry rallies around a new architectural approach that promises to solve all our problems. A few years ago, we all wanted to be micro and distributed. Microservices for the win!

Now, we hear the “modular monolith first!”.

It sounds great in theory but can fall short in practice. In practice, too often:
- module boundaries erode,
- resource isolation is absent,
- promised "easy split" rarely happens,
- ease of deployment is not so easy, as CI/CD tooling is not existing or absent.

I was a bit fed up with the blank advice to go monolith first and covered stuff that, too often, is missed by the folks overselling this idea.

I’m not against monolith-first. Moreover, I agree with the general principles, but I wanted to debunk some myths around it.

The modular monolith isn't a free lunch.

It’s not precise to say:

“If you cannot deal with monolith, microservices won’t work for you!”.

The actual phrase should be:

"If you can’t deal with modularity, then neither monoliths nor microservices will work for you."

If you try to cheat and select modulith-first to cheat using a simplistic solution, it won’t help you; you will probably end up with a big ball of mud.

Monolith-first can give you a gradual process of reaching maturity, but you need to plan it and consider that the DevOps process related to it and tooling is not as simple and mature as glossed.

So, if you’re considering whether to go with microservices-first or monolith-first, you may be thinking the wrong way.

You should go Modular-First and then think about your deployment strategy.

What are your thoughts?

💣 Boom here comes the big news! I made the #ArchitectureWeekly a fully free newsletter. Yes, all the past articles and videos are free. Why did I do it?

https://www.architecture-weekly.com/p/whole-architecture-weekly-content

I believe that all of that gives you more content than a lot of books or paid online courses.

Why did I do it? Am I mad? What’s the catch?

In past years, I delivered many unique materials. I also increased the number of subscribers, both paid and regular ones. Preparing the type of content that I try to deliver each week quality content, takes time and focus.

I still want to do that and produce new articles, but I decrease the pressure to do full-length and deep dives each week—sometimes even on weekends. And I’m not sure how about you, but I prefer to spend weekends with my family.

The number of paid subscribers grew, but still insufficient to fully focus on Architecture Weekly. That’s fine, as I have other work, such as consultancy and training, open source work, and contracts.

I believe that making the Architecture Weekly free newsletter should free some time for me, reduce the pressure I put on myself and let me focus on other stuff.

I still plan to deliver similar content as I did, keeping the weekly cadence, maybe in a slightly different form, or changing it to every other week later on. We’ll see.

So if you worry, don’t. I don’t plan to shut it down, but do it more for fun than profit. Quality should still be here, but maybe a bit lightweight form.

I would appreciate it if you shared the news with your friends, so they could also benefit from those free materials. I believe they’re worth it.

What are your thoughts?

So you want to break down monolith? Read that first. The obvious advice is to use the Strangler Fig pattern, and gradually replace the old code, until it's fully brand new.

Let me tell you something: your monolith will survive. Maybe partially, but it will. I haven't seen a complete monolith migration succeed.

Most were left in the middle of transition after going far above the planned time for rewrite.

Some finished the migration, but replaced the old legacy with the new legacy after rushing the deadline.

Some didn’t even manage those phases, as they sunk product and budget and were thrown away.

So, the safe assumption is that some part of the old system will remain and continue running.

After doing and observing numerous breaking-down-legacy-monolith operations, I've seen a clear pattern: teams fixated on architectural purity generally fail, while those focused on business value succeed.

The most effective migrations aren't driven by trendy tech or eliminating monoliths completely. They start with specific business needs - faster delivery of high-value features, better resilience in critical components, or enabling team independence.

Here's what I've found works consistently:
- focus on the features that extraction makes sense business-wise,
- define measurable business metrics before starting, not just vague technical goals
- be skeptical of customer feedback that isn't backed by behavior data,
- migrate in small vertical slices, learning and adjusting as you go,
- of course do strangler fig eventually.

Most systems benefit from a pragmatic architectural mix. Some components genuinely need to be independent services, while others work perfectly in a monolith. Some may not fit perfectly but:
- work well enough,
- are changed rarely or
- are not a priority for business,
so why change them?

Architecture should serve the business, not the other way around. Read the full detailed guide in the latest #ArchitectureWeekly.

Also, share your failed and successful migration strategy with me!

https://www.architecture-weekly.com/p/so-you-want-to-break-down-monolith

Let’s say it’s Friday. Not party Friday, but Black Friday. You’re working on a busy e-commerce system that handles thousands of orders per minute. Suddenly, the service responsible for billing processing crashes. Until it recovers, new orders are piling up. How do you resume processing after the service restart?

Typically, you use the messaging system to accept incoming requests and then process them gradually. Messaging systems have durable storage capabilities to keep messages until they’re delivered. Kafka can even keep them longer with a defined retention policy.

If we’re using Kafka, when the service restarts, it can resubscribe to the topic. But which messages should we process?

One naive approach to ensure consistency might be reprocessing messages from the topic's earliest position. That might prevent missed events, but it could also lead to a massive backlog of replayed data—and a serious risk of double processing. Would you really want to read every message on the topic from the very beginning, risking duplicate charges and triggering actions that have already been handled? Wouldn’t it be better to pick up exactly where you left off, with minimal overhead and no guesswork about what you’ve already handled?

Not surprisingly, that’s what Kafka does: it has built-in offset tracking. It does it through internal topic and stores each offset change as a separate messages. Why does it do it this way? Wouldn't be simpler to just store in database the latest position?

That and more I discussed in the latest #ArchitectureWeekly.

Offset tracking may seem like a detail, but understanding it can be critical for smooth message processing. Check to learn more about internals, but also how other tools are dealing with it.

As always, we take a specific tool and try to extend it to the wide architecture level.

See more in 👇 and tell me your thoughts!

https://www.architecture-weekly.com/p/how-does-kafka-know-what-was-the

We've all been there: trying to learn something new, only to find our old habits holding us back. We discussed today how our gut feelings about solving problems can sometimes be our own worst enemy.

Every architectural decision is a trade-off. The trick isn't finding the perfect solution - it's understanding the trade-offs well enough to make informed decisions. Try implementing things in practice, build up some muscle memory, and then revisit whether your paranoia level is too high or too low.

Our paranoia level isn't just about being careful - it's about understanding where that care is most needed. Looking at new technologies means finding the balance between respecting their power and not being afraid to use them.

The patterns that worked before aren't wrong - they're just part of our journey to understanding when different approaches make sense.

The key isn't to become less paranoid as you learn - it's to become more precisely paranoid. To know exactly which parts need your careful attention and which parts can flow naturally from your chosen patterns. That's how you grow not just in knowledge but in judgment.

How do I calibrate my paranoia level? I wrote about it in detail in the latest #ArchitectureWeekly

https://www.architecture-weekly.com/p/defining-your-paranoia-level-navigating

What's your paranoia level, and how do you deal with it?

I promised the next #ArchitectureWeekly a deep dive into React/Tanstack Query. And here it is! https://www.architecture-weekly.com/p/react-query-a-solution-for-frontend

I'm super happy that Tomasz Ducin agreed again to share his extensive look at Frontend Architecture and make it available for free.

We explored if a dedicated tool like React Query can prevent the usual headaches for handling server data like:
- stale info,
- redundant fetching,
- scattered “loading” flags.

It was a lot of learning, all with hands-on explanation. I think that the webinar is a good example of how we can evaluate the exact tool choice in the wider architecture concept.

Watch the full video, drop a comment, and let us know which topics you’d like us to tackle next. 🙂

❤️ for resharing to your friends!

There’s a common misunderstanding that #Kafka “pushes” messages to consumers. In reality, it’s a pull-based system where each consumer actively requests data. This design choice means consumers control their own pace—handy for scaling out your application or gracefully handling temporary slowdowns. Instead of blindly pushing messages that might overwhelm one consumer, Kafka gives each consumer control over how much data it’s ready to receive.

Under the hood, concepts like heartbeats, error codes, and session timeouts ensure consumers stay in sync with the broker, even if one goes offline or a network hiccup occurs.

Heartbeats serve double duty: they confirm a consumer is alive and also act as a signal for rebalancing when something changes in the group.

Rather than maintaining a separate notification channel, Kafka folds these “you need to rebalance!” alerts into its standard heartbeat responses—keeping the design both elegant and efficient.

When you dig deeper, you’ll see how partition assignments, group coordinators, and long polling all fit together to create a surprisingly flexible system.

If you’ve ever wondered how that works, or why knowing cryptic consumer configs like fetch.max.wait.ms or session.timeout.ms can be important. Or even make or break performance, my latest post unpacks these mechanics with hands-on examples.

In new #ArchitectureWeekly edition, I explore the specifics with code snippets and real-world examples, covering session timeouts, error codes, partition assignments, and how each piece can make or break a data pipeline.

That's the third part of my "Nerd sniping Kafka" series.

Give it a read, and let me know what you think!

https://www.architecture-weekly.com/p/understanding-kafkas-consumer-protocol

Let's discuss today how Kafka handles message consumption! We'll start by explaining Consumer Groups and how they manage consumers and data distribution.

Then, we'll explore partition assignments, fault tolerance, and the trade-offs involved in more detail. We'll wrap up with real-world implications of Kafka’s design, comparing it to other solutions and discussing whether it's always as great as pictured.

Kafka model is decent, but it can fall into the following issues:

1. Uneven Partition Loads and Processing Skew

2. Processing Pauses During Rebalances

3. Frequent Updates to Offset Storage

4. Handling Workload Changes Inefficiently

5. Rebalance Churn in Dynamic Environments

That stuff can be ignored in the dev environment, but when you're in production, that stuff can give you a serious headache.

Want to learn more? Check the latest #ArchitectureWeekly and drop me a note on how you liked it!

https://www.architecture-weekly.com/p/kafka-consumers-under-the-hood-of

Thinking of building “one #platform to rule them all”? You’re not alone—and it’s trickier than it seems. Right before Christmas, I wrote a post about the hot topic. As my thoughts spin up some good discussion, I expanded it in the latest #ArchitectureWeekly.

I discussed why these big, central solutions usually peak after 1–2 years, then erode under patches, shifting priorities, and detachment from real business needs.

I also brought insights from the 2024 #DORA Accelerate State of #DevOps report, plus stories from Spotify, Stack Overflow, and more.

I see many of my clients trying to apply it, some succeeding, some more, but all struggling. I’m not an expert in building internal platforms, but I was a part of the core teams, shaping continuous integration and delivery processes, and I see many similarities.

If you’re curious about my experience staying sane and keeping your platform or core team on track (without becoming that giant one-size-fits-all monster), check it out!

https://www.architecture-weekly.com/p/thoughts-on-platforms-core-teams

And that’s a free post, so if you enjoyed it, feel free (pun intended) to share it with your friends!

I would also love to hear your thoughts!

Last month I’ve made the Black Friday „offer”. And results surprised me. I gave 30 days trial for free to #ArchitectureWeekly.

Anyone could subscribe, read all articles, watch all videos (over 30h) and decide whether to stay.

I think that it’s fair for old subscribers and good option for new.

What’s the surprising part? Out of 60 people who gave it a try over 30 decided to stay with paid subscription. That’s a lot, as currently after that I have 197.

Super happy about the trust.

I reshaped the format last year, hoping to make it sustainable. I’m still not fully there yet, but that brought me closer. And enough to continue trying.

Thanks!

It seems that you can give #ArchitectureWeekly as a gift. That’s probably not the best gift you can give for Christmas but still better than socks or photo frame, so there you have it https://www.architecture-weekly.com/subscribe?gift=true&utm_source=holiday-gifting-header&utm_medium=web 🤷‍♂️🎅

Read my full take in the latest #architectureweekly https://www.architecture-weekly.com/p/on-getting-the-meaningful-discussions

What are your tricks for having decent design discussions? 🤔

3/3

In the latest #ArchitectureWeekly, I want to be less techy and focus more on the soft part of being an architect. I uncovered some of my tricks for striking a balance between talking and not talking and for using talking to achieve the outcome.

I explained why I think that we should:
1. Ask and listen more often than tell
2. It’s okay to agree to disagree
3. Split the discussions on facts from discussions on feelings.
4. Focus on similarities, not differences.
5. Avoid jargon at all costs.

This week, a surprising thing happened to me. In #ArchitectureWeekly, I try to share my perspective experience every week, but I don't like acting as an expert. That's why I am inviting special guests who know specific areas much better than I do. Sometimes, there are webinars, sometimes podcast-like interviews. What's the surprising part?

In this week's episode with @hazelweakly we discussed observability, and Hazel made us switch places, and she started interviewing me

That's why I'm happy that @hazelweakly agreed to record the #ArchitectureWeekly podcast episode and try to bridge those two perspectives.

https://www.architecture-weekly.com/p/applying-observability-from-strategy

@hazelweakly is one of the best people in the observability space. I think that she doesn't need an introduction here as one of the persons who made the Hachyderm instance operable, safe, and community-driven.

That's also where we started the episode, but we went much further! Also beyond the #OpenTelemetry

I’ll give you two numbers: 15 and 47. What are them? 15 is the number of hours left to get a 30-day FREE trial to all #ArchitectureWeekly content.

47 is the number of people decided to give it a go!

So don’t wait, click here: https://www.architecture-weekly.com/blackfriday2024

Read all articles, watch over 40h of video learning materials and decide whether you stay longer or just benefit from free knowledge!

If you like it, share with your friends so they can also benefit! 🙂❤️

#ArchitectureWeekly

Client Info