When is it time to make system changes?

Published 3 months ago • 1 min read


This week I'd like to shortly discuss a decision making process when it comes to making large system changes, here's a quote and a link to a nice blog post I've read yesterday:

We should always put off significant complexity increases as long as possible.

The post above tells the story of a team running a large monolith with one large database which they kept scaling up for years.

At one point, it reached 80% load with short bursts of downtime, but there was nowhere to grow in terms of scale.

This leaves the time with one of two basic options:

  1. Redesign the system (microservices? sharding? different DB?)
  2. Taking the less exciting path of debugging the source of struggle and slowly improving (code, queries, internal configs)

There's no right or wrong, but a very important statement made in the post and that I find myself reiterating at work is:

Making system changes will be expensive, but not because of technology, mainly for engineering hours and attention.

While the bold statement above is often overlooked, it's not only this should be considered when decided how to make progress, it should also be taken within the context of the situation:

  • Is the system on fire?
  • Do we expect fires to happen for some time?
  • Are we looking at growth? Exponential? Or gradual?

With a clear picture, it's easier to make wiser decisions that are contextual and informative.

This may be obvious to some, but in many cases even senior leaders tend to jump on the latest trend (I know I did) and let enthusiasm take over better judgment.

When I used to be in the consultant's shoes (but often one that had to follow his own advice and implement the changes), it was easier for me to view things through a different unbiased lens, which I try to keep in mind even today.

The takeaway here is, what would you do if you were a consultant? What's the context here? How would future-you look back at this decision a year from now?

With that in mind, have a great weekend! And here's a few interesting things I've discovered / read / tried over the past week:

You can find me on other channels as well:

📺 :

🎤 :

✍️ :


Every once in a while I send hand picked things I've learned. Kind of like your filter to the tech internet. No spam, I promise!


Hi friends, Here's a quote from Deep Work which I'm 30% through the second reading round: Focus intensifies by getting used to NOT being distracted. And can improve with practice.” - “Deep Work”, Cal Newport An MIT recent study shows that when the brain forms memories or learns a new task, it encodes the new information by adjusting connections between neurons. They also remind of the principle of “neurons that fire together, wire together”, proposed by Donald Hebb in the 1940s. This is...

6 days ago • 3 min read

Hi! Today I want to share a security researching flow Disclaimer: I am not a security expert. Disclaimer II: Every story and example shown here were either made with Prior consent My own systems As part of a VDP (vulnerability disclosure) The WHAT For the next magic trick you’re going to need - A browser - A proxy - A pair of eyes Easy, right? I’m assuming most readers have at least 2/3 but never made them work together to get an insight into how their browser interacts with the...

20 days ago • 2 min read

Hi! Let’s say you’re an entrepreneur, you know what, a “solopreneur”. You have you own side gig and it’s making a few hundred bucks a month. If I told you you can lost the entire thing in a heartbeat because you missed something, you’d be anxious to know what it, right?​Rewind 34 months, I was sitting at my desk, assisting the frontend team in troubleshooting their configuration issue. As I opened the devtools pane and launched the network tab, my goal was to locate "config.json". However,...

27 days ago • 3 min read
Share this post