DEV Community: Vladi Stevanovic

We asked people not to upvote us on Product Hunt and ended up #8

Vladi Stevanovic — Wed, 01 Oct 2025 07:56:52 +0000

Like a lot of startups, Multiplayer has been going through some big changes lately.

We’ve doubled down on what we believe in (full stack session recordings), and decided to go all in on the usual GTM playbook: launches, talks, docs, community, the works.

And of course, somewhere on that playbook checklist is the rite of passage: Product Hunt.

Now, I’ll be honest: I’m not usually lurking on Product Hunt. I’m more of a “heads down in docs, building with users, hanging out in obscure Slack channels” kind of person. Also, Product Hunt is just one of the many activities we planned to raise awareness, and not even the most interesting IMO.

But before launching, I tried to do my homework.

I read the Hacker News threads. I saw the pieces about how “Product Hunt is dead,” how the game is rigged with launch agencies, paid boosts, and the same handful of giants always climbing to the top.

So I went in with realistic expectations.

I thought I was ready. Spoiler: I wasn’t.

Scheduling your launch is… a thing?

None of us had posted in Product Hunt in years. Our designer was the most active user but even his main activity was mostly in 2016 when he "hunted" Slack Beta! 😅

Imagine our surprise when we learned you can’t just hit “publish”. You actually have to schedule your launch for a specific day.

We picked Tuesday. No special strategy, just Tuesday.

Turns out Tuesday is the day. A kind of Thunderdome for launches. That week? Claude, DeepSeek, OpenAI, Lovable, Squarespace… basically the Avengers of product launches.

So within minutes, we looked at each other and said: “Okay, we’re not winning this game. Let’s not even try. Let’s just play it for the feedback.”

Feedback > upvotes

That became our mantra. We literally told people NOT to upvote us. Our CEO even sent an email saying, “Don’t upvote us, just give us feedback.”

And people did. By email, in DMs, on our social. We received some insightful feedback on Multiplayer features (and what people liked and wished to see on our roadmap), and that was way more valuable than any orange number on the leaderboard.

But somehow… #8?!

Here’s the twist: even though we weren’t gunning for the top, we ended up #8. Above Lovable. Above OpenAI (?!).

To be clear: I’m not about to start believing Product Hunt is suddenly fair, or that it’s worth sinking weeks of effort into having a "successful launch". I’m still skeptical.

But I am grateful for everyone who left a comment, shared a thought, or yes, upvoted anyway.

The takeaway

Launching on Product Hunt didn’t magically change our trajectory. It didn’t flood us with signups or website visits.

But it did give us a moment to tell our story, collect real feedback, and laugh at the absurdity of finding ourselves in the top 10 on one of the busiest launch days of the year.

At the end of the day, I’ll take feedback over upvotes any day.

(Though… if you want to roast me for picking Tuesday of all days, or just plain launching on Product Hunt that’s fair too 😅).

Networking for Engineers: A Guide to Surviving Tech Conferences

Vladi Stevanovic — Mon, 17 Mar 2025 10:27:45 +0000

Tech conferences are filled with opportunities—new connections, great conversations, and fresh ideas. But let’s be honest: networking isn’t easy, especially if you’re an introvert, new to the industry, or just not sure where to start.

As a Community Director, I’ve seen how awkward (and sometimes painful) these interactions can be, even for experienced engineers.

I'm heading to Kubecon + Cloudnative Europe 2025 in London in a few weeks with my team at Multiplayer.app and I wanted to share practical, low-stress tips to meet people, have meaningful conversations, and leave the conference with more than just a pile of swag.

Networking 101: The Basics

Before we dive into conversation starters, here are a few golden rules for making better connections at conferences:

Engage and Listen First

Let people tell their story before jumping in, even when you have something in common (“Oh, I play the guitar too, let me tell you about this new song I've been working on...”).

It's important to be present, not just waiting to speak – It’s obvious when you’re distracted or just thinking about your next line. Not to mention you might miss a very important point they are trying to make and which would lead to a more meaningful conversation (i.e. which your original "next line" might not even have addressed).

Don’t Sell—Just Connect

Most people attending a tech conference do it for work - whether that's finding new clients, expanding their professional network or learning new skills. However, the most meaningful conversations happen when you're genuinely looking to connect on a personal level, rather than just thinking "how can I use this person to my personal advantage”.

Not to mention that, if they’re interested in what you do, they’ll ask. Keep it simple, for example:

“I work at Multiplayer — we build tools for devs working on distributed systems. Right now, we’re focused on auto-documentation and platform debugging using OpenTelemetry, which is why I'm enjoying the talks at Kubecon so much!”

Don’t Center the Conversation Around You (or Them)

Avoid making it all about you, proving your knowledge, or flexing credentials. That doesn't leave many openings for the other person to genuinely progress the conversation.

At the same time, be aware that - contrary to what we often hear - not everyone likes to talk about themselves. So be prepared with follow up questions about mutual interests (the conference, the talks, the tech, etc.).

Skip the Handshakes and Business Cards

Unless someone offers first, skip the handshakes. Also no need to prepare business cards: most connections are digital now anyway (and I have a useful tip later in the article 👇).

How to Start Conversations at a Conference

After all these "don't" you might be wondering but how DO I start a conversation.

If you're not sure what to say, these openers make it easy to strike up a conversation naturally—without feeling forced or awkward.

Before a Talk (Turn to Your Left)

“Hey, I’m [name]. Nice to meet you. It’s always fun hearing what brought people here. What’s your KubeCon story?”

“[follow up] What session did you see today / what session are you heading to next?”

“[follow up] Any after-party events on your list?”

“[follow up] What got you into tech?”

After a Talk (Turn to Your Right)

“That was a great session. What did you think? Did it align with your experience?”

“That talk made me realize I need to look into [technology/tool]. Have you used it?”

“I’m still wrapping my head around [topic]. Have you worked with it before?”

In Low-Traffic Areas (Spotted Someone Alone?)

“Hey, looks like we’re both in the same boat waiting here. Is this your first KubeCon, or are you a veteran?”

“[follow up] How did you first get into [topic]?”

“[follow up] What’s your strategy for surviving a conference this big? I feel like I need a game plan.”

“[follow up] Do you know anyone else at this event?”
(yes) “Do you mind making an introduction?”
(no) “Let’s go meet someone together.”

Standing in Line (Registration, Coffee, etc.)

“Are you waiting for [xyz] too? I always find the hallway track (random convos) just as interesting as the talks. Heard any good discussions today?”

“[follow up] That sounds interesting! Have you worked with that tech before?”

“[follow up] If you had to pick one must-see talk for me, what would it be?”

If You See Someone Eating Lunch Alone

“Mind if I join you? I’m trying to meet more people in the community.”

“Are you here with a team, or flying solo?”

“[follow up] What made you decide to attend this year?”

“[follow up] What’s been the most valuable thing you’ve gotten from past KubeCons?”

Joining a Group Sitting Down

“Can I put my drink/bag here?”

“[follow up] Are you all talking about [topic]?”

“[follow up] Do you all know each other, or did you just meet here?”

Chatting in the Hallway with a Small Group

“Hey, do you mind if I join?”

“Hey, I don’t know many people here yet—mind if I introduce myself?”

Sitting Alone at the Expo

“So, what’s caught your eye in the expo so far?”

“[follow up] What makes that stand out to you?”

“[follow up] Have you tried implementing something like that in your work?”

“[follow up] Are you looking for a specific solution, or just browsing?”

Approaching a Speaker

“I loved [topic]—how did you come up with that concept?”

“[follow up] Thanks for taking my question—could you clarify [topic]?”

“[follow up] How long have you been working on that talk?”

At an After-Party

“Hi, I’m [name]. How’s the conference been for you so far?”

“[follow up] What’s been the highlight of your conference so far?”

“[follow up] What’s a challenge you’re currently trying to solve in your work?”

How to Exit a Conversation Gracefully

Not every conversation will be a great match. If you need to step away, here are some polite ways to do it:

“Excuse me, I need to grab a refill.”
“I need to step out for some air before my next talk.”
“I have to check in with a colleague—nice meeting you!”

If it's a great conversation, and you want leave it on a positive note and stay connected:

“I really enjoyed our conversation—let’s keep in touch on LinkedIn.”
“I’d love to continue our discussion on [topic]. Want to schedule a follow-up chat?”
“Before I head off to my next talk, would you like a sassy sticker I designed?”

LinkedIn tip!

To make connecting on LinkedIn super quick, I like to add my LinkedIn QR code on my wallpaper.

And if you plan to also schedule follow up meetings, you could add a QR code to your calendar link, and add that as your home screen.

Here's an example:

Questions to Avoid

Some questions seem harmless but can put people on the spot. Here’s what to steer clear of:

🚫 Where are you from? → Not everyone is comfortable sharing.
🚫 What do you do? → What if they’re unemployed or in a job transition (or simply don't enjoy their job)?
🚫 Where did you go to school? → What if they’re self-taught and didn't have the opportunity to pursue a degree?
🚫 Anything political or controversial. → Not the time, not the place.

Final Thoughts: Networking is About Building Relationships

Good networking isn’t about pitching, selling, or handing out business cards—it’s about building real connections.

If you’re attending KubeCon (or any other tech conference), focus on being curious, listening more than you talk, and making others feel comfortable - or come find me, I'd love to have a chat!

And if all else fails—just ask about the best talks, the best tech, or where to get the best coffee.

See you at KubeCon! 👋🏻

The worst advice on diagramming I've ever read

Vladi Stevanovic — Fri, 27 Dec 2024 13:54:23 +0000

I’ve recently come across this advice for diagramming system architectures:

“Prioritize abstractions over details: Abstract information is still correct, it’s just leaving out some detail. Leaving out details reduces the chance for errors and the need for constant updates. Have the courage to leave things undocumented (better no documentation than wrong documentation). Document only those parts or aspects of your system and its architecture that are definitely required by stakeholders.”

It struck me HOW WRONG this advice is.

I started to explain to my colleagues why this was such a disappointing (and counterproductive) advice but there was just SO MUCH wrong about it.

So here’s a blog post.

1^ Wrong Thing: Over-prioritizing Abstractions

I understand the intrinsic value of abstractions to quickly and effectively explain complex concepts. I also completely agree that when brainstorming or explaining a system it makes sense to rely on abstractions.

That said, arguing that your documentation should prioritize abstractions is a recipe for misunderstanding, frustration, and, ultimately, useless docs.

Over-prioritizing abstractions means you omit key information that are necessary to understand how a system operates. Furthermore, without sufficient detail, developers and other stakeholders risk making flawed assumptions about how components interact, leading to incorrect architectural decisions.

Not to mention that when something breaks, overly abstract diagrams don’t provide the actionable information needed to locate and resolve issues.

In short, you may use your abstracted diagram during the first day of onboarding and nothing else, because already on the second day your new teammate will have more questions than that diagram can answer.

2^ Wrong Thing: Leaving Out Details

Modern distributed systems—effectively most systems nowadays—involve intricate dependencies, APIs, and external integrations. Omitting details makes it nearly impossible to map how systems truly behave in production.

“Leaving out details reduces the chance for errors and the need for constant updates.”

What are we optimizing for here? What is the purpose of this document? Is it just to check a box?

It sounds like advice for how to spend the least amount of effort on writing a must-have document, that you have to touch the least number of times. Again, who is this serving?

Architectural documentation—diagrams included—should be in service of helping engineers (and various other stakeholders) understand their system.

If we assume that this diagrams has to be useful, then it has to be accurate, thorough and updated.

I’ve written ad nauseam about the reasons why documentation is painful, and most recently I’ve reached the conclusion that traditional documentation practices will always fall short.

But there ARE WAYS TO KEEP DETAILED DIAGRAMS updated, least of all using tools that use your own system as the source of truth.

3^ Wrong Thing: Assuming Diagrams Are Always Outdated

As long as we continue to use diagramming tools built for static images instead of purpose-built for developers, we will continue to see diagrams as a burden.

When you have to constantly battle with arranging boxes and connecting arrows — knowing that at the next PR your perfectly designed diagram will already be out of date — of course the advice is to make it as “abstract” as possible so you don’t have to waste as much time to update it.

But the truth is that dynamic, accurate diagrams are possible.

Modern tools make it possible to create diagrams that evolve with your system, maintaining accuracy and reducing manual overhead. For example, Multiplayer’s System Auto-Documentation can address the challenges of keeping documentation up-to-date without sacrificing detail.

4^ Wrong Thing: Assuming Info can be Found Elsewhere

If the diagram of your system architecture is incomplete / outdated, then where do you expert your engineers to find this information?

I can already hear the comments: “Just read the code”. Which goes hand in hand with the good old “self-documenting code” myth.

It’s not bad advice per sé, it just assumes that you (a) have the time to read, understand and reverse-engineering how the system works and (b) have the knowledge to do so (remember, there are many stakeholders that benefit from understanding how a system works, engineers are only one of them).

But let’s assume that (a) and (b) are not a problem for you. Let’s also assume that team turn over, tacit and tribal knowledge are also not an issue when it comes to institutional knowledge.

How about the frustration of looking for information where it should be (documentation), not finding it, having to search for it, maybe having to ask a colleague, having to wait for an answer,…

Context switching fatigue is real.

5^ Wrong Thing: Encouraging No Docs Over Wrong Docs

We all know that documentation is a task that often ends in the backlog or that outright ends fully ignored because of tight deadlines, GTM priorities, etc.

Saying "Better No Documentation Than Wrong Documentation" is like saying that you can confidently rely on tribal knowledge. Tribal knowledge is a good resource, but it cannot be THE ONLY resource to understand the system architecture.

An attempt at documentation is always better than no documentation, at the very least as a historical snapshot of the system or the architectural decisions made in that moment. It’s a starting point for understanding the system. Teams can cross-check it with the current state and update it as needed. Having nothing to reference makes it harder to orient new team members or debug issues.

Saying no docs are better than wrong docs, is like saying no wifi is better than slow wifi. Slow wifi is very (VERY) frustrating, but at least I can get SOME work done.

But this point is wrong also because it effectively says that you shouldn’t build a culture of documentation unless the outcome is accurate documentation.

Indeed you should build a culture of documentation even if you may be using sub-optimal tools and processes at first because documenting your design decisions, trade offs, architectural conversations is worthwhile and it serves your long-term project longevity.

Conclusion

I honestly could go on.

For example the sentence “Document only those parts or aspects of your system and its architecture that are definitely required by stakeholders”. Which stakeholders? Developers have different requirements than DevOps, QA, PMs, Managers, etc. Is the recommendation to create an individual diagram tailed per stakeholder group?

Again, another issue that could be solved with a dynamic diagram and using the right tooling.

I don’t mean any hate towards the author of this advice. In fact it was within an article that presents other useful tips on diagramming.

However, what bothers me most about this advice is that it reflect an outdated view of diagrams and documentation - it views them as an artifact that you have to create, maybe as part of a top-down, ivory-tower style architectural process.

It assumes and accepts that documentation is painful and it tries to minimize the effort involved.

Instead, I believe developer tools and practices have advanced enough to allows to have our cake and eat it too: be able to document our systems in detail and in real-time without having to sacrifice large amount of time and effort.

[Part 4] Effective Measures to Control System Architecture Drift

Vladi Stevanovic — Wed, 28 Aug 2024 13:52:02 +0000

Given the significant impact of architectural drift on a software system’s maintainability, performance, and overall quality, proactive management is essential.

Teams can employ three types of measures to control system architecture drift:

(1) Organizational Competence

Engineering teams must possess the architectural skills necessary to build robust systems. Beyond mere technical knowledge and experience in architecting systems, fostering a culture where system architecture is regarded as an ongoing team responsibility is crucial. Encouraging collaboration and a shared understanding of the architecture, along with its guidelines and principles, reduces the likelihood of unauthorized deviations, redundancies, and uncoordinated additions.

(2) Proactive Prevention Methods

Adopting best practices like (some) upfront system design and continuous system design reviews ensures that potential architectural drift is caught as early as possible. While reactive measures can discover and address drift after it occurs, they often lead to labor-intensive and ultimately ineffective solutions like major refactoring. Ultimately the root cause of the accumulated architectural technical debt is the way the team approaches development, and if that is not addressed, the same problems will reappear.

(2) Tools for Detecting Architectural Drift

Utilizing tools that automatically detect changes and drift in the system’s architecture, dependencies, and APIs is fundamental. Ideally, these tools should also (a) visually represent system changes to easily identify deviations or inconsistencies, and (b) enable proactive design reviews to stay ahead of drift. An ideal tool would also provide comprehensive and up-to-date system documentation, ensuring that the team fully understands all architectural decisions, past and present.

A well-defined and enforced architecture enhances a system’s testability, documentation, and extensibility. Such attributes contribute to increased development velocity, quicker onboarding of new developers, and greater agility, allowing organizations to respond more swiftly to market demands.

In conclusion, managing system architecture drift is a vital aspect of software development and it’s highly dependent on how an engineering org approaches system design.

It necessitates vigilant and proactive management and requires teams to have the right tooling so they can “see around corners.” By understanding its nature, causes, impacts, and implementing effective control measures, teams can maintain a stable and adaptable architecture.

What's Next

For more about system architecture drift check out these next articles:

101 on Architectural Technical Debt
[Part 1] Delving into Architectural Drift
[Part 2] Architectural Drift in Real Life Systems
[Part 3] The Temptation to Ignore Architecture Drift

Thank you for reading! 💜

[Part 3] The Temptation to Ignore Architecture Drift

Vladi Stevanovic — Wed, 28 Aug 2024 13:51:09 +0000

The gradual nature of architectural drift, with its incremental changes that often go unnoticed or don’t immediately “break the system”, often leads developers to overlook or dismiss its significance.

However, akin to the insidious spread of rust or rot, architectural drift gradually deteriorates the original composition and structure of an application, having a direct technical, business and cost impact.

(1) It paves the way for future complications.

When we introduce unaccounted-for architectural decisions, we open the doors to a range of issues:

Security Risks: Introducing unexpected resources or deploying them incorrectly can create security vulnerabilities, particularly if these changes escape the notice of the security team.
Delayed Feature Implementation: Deviating from the intended architectural blueprint complicates the integration of new features, potentially impairing the system’s ability to adapt to evolving business demands.
Resource Misconfigurations: The increasing complexity resulting from architectural drift amplifies the likelihood of misconfigurations, leading to deployment issues. This is exacerbated in environments where multiple teams deploy to a shared cloud, raising the risk of resource conflicts or redundancies.
Escalating Costs: Incremental enhancements to the architecture can cumulatively inflate cloud expenditure significantly.
Unmonitored Resources: Departure from the planned architecture might render existing management and maintenance protocols ineffective, leaving behind unpatched and potentially vulnerable resources concealed within the architecture.
Higher Engineering Overhead: An unplanned architecture demands more maintenance and resources, particularly for sub-optimal choices or solutions not aligned with the architectural roadmap. This complexity not only increases the costs associated with system upkeep but also prolongs the onboarding and offboarding processes, given the undocumented nature of system modifications.

(2) It highlights issues with the original architecture.

Architectural drift may not always be bad news! Drift that occurs in response to new requirements — which could not be satisfied within the confines of the system’s existing architecture — can highlight previously overlooked but crucial design elements.

It’s imperative to understand if the original architecture was inherently flawed so teams can take appropriate steps to address the problems.

Ignoring architectural drift is akin to turning a blind eye to the slow but sure erosion of a system’s integrity and functionality. Over time, the accumulating gaps between the actual architecture and the intended architecture can lead to decreased maintainability, reduced system performance, and increased complexity.

What's Next

For more about system architecture drift check out these next articles:

101 on Architectural Technical Debt
[Part 1] Delving into Architectural Drift
[Part 2] Architectural Drift in Real Life Systems
[Part 4] Effective Measures to Control System Architecture Drift

Thank you for reading! 💜

[Part 2] Architectural Drift in Real Life Systems

Vladi Stevanovic — Wed, 28 Aug 2024 13:49:58 +0000

Recognizing and addressing drift is not just about maintaining the system’s current state but about safeguarding its future agility and robustness.

This is particularly evident when looking at real-life examples of architectural drift and its consequences. For example:

Linux Kernel

A research group compared the Linux Kernel main subsystems architecture documentation with their source code. After manually reverse engineering the software architecture from the code, they found significant architectural drift and erosion: there were a number of violations between the prescriptive, recorded architecture and the actual architecture.

Besides the surprisingly high number of (unnecessary) dependencies between the components, what is most striking is that interviews with the developers surfaced that they were unaware of the architectural degradation. A common reason given was “it had to be done fast, and I didn’t have time to go back and update the documentation”.

X (formerly Twitter)

At the beginning of 2023, X (formerly Twitter) encountered severe issues and service disruptions as a direct consequence of the sweeping layoffs of significant portions of the engineering teams who designed and build this massive social network.

Elon Musk himself admits that the X system architecture is massively complex:

"The code base is like a Rube Goldberg machine, and when you zoom in on one part of the Rube Goldberg machine, there’s another Rube Goldberg machine, and then there’s another one, so it’s quite difficult to keep this thing running, and then also difficult to advance the product because it is really overly complex, to say the least.” — Elon Musk at the 2023 Morgan Stanley TMT Conference

And there is convincing evidence that high architectural complexity is linked to a much higher defect rate (in addition to a decline in productivity, and system understanding).

However, the timing and nature of these disruptions is indicative of additional underlying issues: the layoffs not only reduced manpower but likely led to a loss of critical institutional knowledge regarding the system’s architecture. This gap in recorded system information, combined with the existing architectural drift, compounded the challenges faced by the remaining team in diagnosing and resolving the service disruptions.

There are countless examples of real-life issues caused by architecture degradation, highlighting the importance of proactively addressing architectural drift. They range from the Hadoop developers not realizing that 61 out of the 67 components in the system had circular dependencies, to the Knight Capital Group going bankrupt in 45 minutes (partially) due to deleting code that was thought to be “dead” but was still actively used.

What's Next

For more about system architecture drift check out these next articles:

101 on Architectural Technical Debt
[Part 1] Delving into Architectural Drift
[Part 3] The Temptation to Ignore Architecture Drift
[Part 4] Effective Measures to Control System Architecture Drift

Thank you for reading! 💜

System Design Resources that are Not ByteByteGo

Vladi Stevanovic — Mon, 03 Jun 2024 16:29:47 +0000

System design is a core engineering skill and everyone on your team should have some degree of understanding of their system’s architecture.

In addition to that, with the rise in the adoption of AI coding assistants, mastering this skill will safeguard your professional career ensuring that you remain relevant and productive in an evolving technological landscape.

Traditionally, junior developers have been taught to focus primarily on learning coding skills and mastering the fundamentals of their chosen technologies. However, AI assistants, like GitHub Copilot, are significantly accelerating coding tasks—55% of users report coding faster. This acceleration frees up time for developers to delve deeper into system intricacies, thereby gaining expertise in the environments they create and adopting a more holistic approach to software system development.

Inbal Shani, former CPO at GitHub, emphasized this shift in mindset:

Developers need to form a different thinking […] more systems, more architecture. You need to start figuring out how to use the AI tools to help you be successful. It's no longer just the actual code writing, it's really evolving your thinking to see the big picture, the connected experience, and the connected systems.

This mindset, once primarily associated with senior software engineers, is now becoming essential for all developers. The gap between senior and junior developers is narrowing, especially as 92% of developers are already leveraging AI tools.

👉 The time to start learning system design is now. 👈

Problems with the Current System Design Discourse

Unfortunately, the discourse around system design often centers on “how to ace a system design interview”. While it's true that system design is a critical skill for many organizations, particularly given the prevalence of distributed systems, this focus on interview preparation neglects the importance of applying these skills in day-to-day, real-world scenarios.

This hyper-focus on technical interviews is akin to the institution of standardized testing—it has its uses but is inherently limited. It fails to provide a complete picture of the real-world challenges and the creative, adaptive thinking required to effectively apply system design knowledge and skills in practical contexts.

Furthermore, the industry is currently experiencing a shift in the role and significance of Software Architects. We're recognizing that system and software design are not confined to specific roles; every engineer should possess some level of proficiency in these areas. Having system design experience and considering architectural requirements during coding makes you a better engineer and leads to superior products.

However, many engineers and organizations have yet to embrace this trend, maintaining a strict differentiation between engineers and various types of Software Architects.

Lastly, the most significant issue: system design is often misconceived as merely diagramming, producing specific documents, or adhering to codified frameworks. In reality, system design is an ongoing process that outlines the high-level conceptual structure of a complex system (the system architecture) and defines its major components and interactions. While it can result in outputs such as system diagrams, Architectural Design Records, or the use of specific tools and frameworks, it encompasses how a team builds software and not just the tools that they use to help throughout the process.

Resources you usually see

When researching system design, the internet often surfaces two primary resources:

I want to emphasize that both are extremely helpful and I highly recommend them. In fact, we are subcribers to - and avid fans of - the ByteByteGo Newsletter and its authors Alex Xu and Sahn Lam. Conveying complex concepts in a fun and visual way is an art and reading their newsletter is always a pleasure.

Likewise, it’s fascinating to learn how companies like Netflix, Google, Stripe, or Spotify design their systems and discover the clever solutions they’ve implemented. However, chances are you’re not working on a system as mammoth as theirs and their approaches are often tailored to these specific use cases.

Indeed, there is no single right way to architect a system. The design depends on your business requirements, development stage, and the trade-offs you’re willing to make.

Underestimated System Design Newsletters

In addition to ByteByteGo and various corporate blogs, I highly recommend checking these resources. They are not mentioned nearly as often, but they can teach you a lot about system design:

📌 NB. These are just general categories that helped me categorize them, so there is some overlap.

Fundamentals of System Design

“System Design Codex” by Saurabh Dashora
“Distributed Systems Architecture” by Thomas Johnson
“Architecture Notes” by Mahdi Yusuf
“Software Design: Tidy First?” by Kent Beck
"Level Up Coding” by Nikki Siapno
“AlgoMaster” by Ashish Pratap Singh
“System Design Classroom” by Raul Junco
“Dev Details” by Mike Thornton
“Tech World With Milan” by Milan Milanović

Big Tech System Design Examples & Recaps

Broader Scope Interesting Newsletters

“.NET & Software Architecture” by Milan Jovanović
“Curious Engineer” by Vivek Bansal
“Technically” by Justin Gage
“Data Gibberish” by Yordan Ivanov
“EcZachly Data Engineering” by Zach Wilson

System Design Books

System design books are also great starting points for deepening your understanding of architectural principles and best practices. Here are some of the most popular ones:

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann
Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Ford
Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford and its sequel “The Unicorn Project”
Building Microservices: Designing Fine-Grained Systems by Sam Newman
The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise by Martin L. Abbott and Michael T. Fisher
Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin
Designing Distributed Systems by Brendan Burns

Helpful GitHub Repos

I also recommend these GitHub repositories for practical examples, tools, and resources to enhance your system design skills and knowledge.

I hope you found this helpful and I look forward to more recommendations in the comments! 💜

Interesting Facts about Software Architecture Styles You May Not Know

Vladi Stevanovic — Wed, 22 May 2024 10:00:59 +0000

When I first began researching this topic, I was faced with a plethora of articles where architectural styles are placed in opposition to one another, such as the well-known monolith vs. microservices debate.

While I understand the underlying intention—to highlight the contrasting approaches and benefits of each solution—focusing solely on comparisons misses the point.

The value of these designs lies not in how they differ from one another but in how they can be leveraged to meet specific use cases and achieve particular business goals. There is no clear winner in the 'microservices vs. monolith' debate because no single system architecture is universally 'right' or 'wrong.’

As Brendan Burns, co-creator of Kubernetes, aptly puts it:

“If you insist on microservicing everything, you’re definitely going to microservice some monoliths that you probably should have just left alone. But if you say, ‘We don’t do microservices,’ you’re probably leaving some agility, reliability and efficiency on the table.”.

Ultimately there are two main truths to keep in mind when choosing an architectural style:

When given a choice, the best approach is to keep it simple - boring even!
Your architecture will (or, at least, should) evolve as your business, requirements, and technological landscape change.

This article is a collection of interesting facts I found while researching the article “Six Modern Software Architecture Styles” - although interesting is indeed subjective 😉.

(1) Architectural Style or Pattern?

Unsurprisingly, as with many IT terms, “Architecture Styles” and “Architecture Patterns” are often used synonymously, while other times they are treated as distinct categories of software concepts.

The confusion became so pervasive that I had to sit down with my team to decide on the terminology we would use to stop confusing ourselves further (that’s also how I ended up writing “System Design and Software Design in Distributed Systems”).

We landed on these definitions:

Architectural Style: It’s the overall structure and organization of a software system from a 10,000-foot view, showcasing the highest level of system design abstraction. Architectural styles address fundamental questions about how system components communicate, how data flows, and how the system is divided into modules or layers. Changes to an architectural style are significant and can be costly, as they involve restructuring the fundamental aspects of the system and can have a long-term impact on the project.
Distributed System Design Patterns: These are frequently used solutions to common industry problems related to data storage, messaging, system management, and compute capability. Examples of common Distributed System Design Patterns include Ambassador, Circuit Breaker, CQRS, Event Sourcing, Leader Election, Publisher/Subscriber, Sharding.

(2) Monolithic Architectural Style

In recent years, starting a project with a straightforward, simple, and performant monolith has often been stigmatized. Yet, many large enterprises like Dropbox, X (formerly known as Twitter), Netflix, Facebook, GitHub, Instagram, and WhatsApp initially built their successes on monolithic codebases. Furthermore, several prominent companies such as Istio, Segment, StackOverflow, and Shopify still rely on them to this day.

Historically, monoliths were the standard in the early days of software development. However, due to some of the more challenging aspects of this architecture, the concept of Service-Oriented Architecture (SOA) began to gain traction in the 2000s. It was during this period that the term “Big Ball of Mud” was coined to describe monolithic legacy architectures.

What’s interesting to me is that the initial idea of the Big Ball of Mud doesn’t match the current image of monoliths!

Today, we often envision a monolith as a tower of rigid, inflexible, tightly-coupled processes, where deploying a simple change to one part of the application might inadvertently affect a completely different one.

However, when Professors Brian Foote and Joseph Yoder originally introduced this term, they were describing a chaotic architecture composed of programs haphazardly piled onto one another, with data exchanged between them via file dumps onto floppy disks.

(3) Microservices Architectural Style

Microservices represent the epitome of modular architecture, where small, autonomous components (modules) operate on separate processes and communicate over networks to form a cohesive application.

Interestingly, the rise of microservices wasn’t solely due to the challenges faced by Service-Oriented Architecture (SOA) implementations, which often struggled with defining clear service boundaries.

There is a direct correlation between the popularity of microservices and the growing need for organizational clarity, autonomy, and independence within engineering teams.

“Amazon, one of the first companies to openly discuss the microservice concept, really wasn't trying to push the architectural principle as much as they were trying to push the idea of an independent development team whose blockers were few and far between.” - Ted Neward

Companies were struggling to optimize developer velocity due to cross-team dependencies. Most organizations were organized into ‘skill-centric’ departments, leading to common development hurdles such as waiting for the infrastructure team to procure a server, waiting for the DBA team to implement a schema change, or waiting for the QA team to develop a test to identify a bug.

Microservices liberate development teams, fostering flexibility that, in turn, accelerating teams' velocity. Teams gain autonomy —deploying their code independently and at their own pace— and can select the most suitable technologies for their specific services, unhindered by standardized, one-size-fits-all approaches.

It also feels like Conway’s Law at work, which states that ‘Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.’

(Another interesting tidbit: engineers at Amazon Prime Video’s didn’t actually migrate from microservices to a monolith, but rather to a “macroservice” - I dive a bit more in detail in my article.)

(4) Event-Driven Architectural Style

Event-Driven Architecture (EDA) complements both Microservices and SOA. It stems from the need of modern digital businesses to respond instantaneously to events, ensuring users receive the most current information and rapid feedback.

With the rise of cloud-native architectures, container-based workloads, and serverless computing, EDA has gained renewed popularity.

However, the concept of components or services communicating through events is not new. EDA has been around for decades, in fact Gartner proclaimed it the “next big thing” nearly 20 years ago!

Maybe the fact that EDA seems like a fairly recent concept might be due to my own skewed perception of time—much like how, as Millennial, the 1980s feel like just 20 years ago, even though it’s already been 40 years.

(5) Serverless Architectural Style

Like all other architectural styles, the principles underpinning Serverless Architecture—specifically, the ability to build and run services without managing the underlying infrastructure—have existed for some time. However, they've become mainstream in software development with the rise of cloud computing, notably since Amazon launched the first widely-used Function as a Service (FaaS) platform, AWS Lambda, in 2014

However, when adopting this architectural style, many engineers may not have top of mind that FaaS providers typically support only specific technologies, and migrating to a different cloud provider can be exceedingly complex and problematic.

Intellectually, the advantages of cloud-agnostic deployment are well recognized, but the practical importance of this flexibility becomes starkly apparent when issues arise that necessitate a migration to another provider.

“His team was using GCP’s Cloud Run, a container service, to host their API. They had a unique use case that required them to call back to their own API to kick off more work. It turns GCP monitors for this type of behavior and flags it as crypto mining. One sunny day, their infrastructure was gone, and their account was locked. They spent the next week working ~18 hours a day to move to AWS.” - Ray Epps

In summary, one of the significant challenges of Serverless Architecture is vendor lock-in - it’s not possible to run the same function with different providers and any migration will require some degree of reconfiguration.

(6) Edge Computing Architectural Style

Edge computing represents an evolution of cloud computing and a variation of the serverless architecture. It brings data and computational power closer to the sources of data production, as well as to the applications and users that consume it, significantly reducing bandwidth and response times.

However, contrary to popular belief, 'speed' is not the primary benefit of adopting this architectural style; rather, it’s compliance.

“Today, I’m convinced that we were wrong when we launched Cloudflare Workers to think of speed as the killer feature of edge computing, and much of the rest of the industry’s focus remains largely misplaced and risks missing a much larger opportunity. I'd propose instead that what developers on any platform need, from least to most important, is actually: Speed < Consistency < Cost < Ease of Use < Compliance.” - Matthew Prince, Co-founder & CEO of Cloudflare

One significant advantage of edge computing is that sensitive data never has to leave the 'edge'—the physical area where it is collected. This is particularly beneficial in light of increasing country specific compliance regulations regarding their citizens’ personal data.

(7) Peer-to-Peer Architectural Style

It can be argued that the foundational concepts of Peer-to-Peer (P2P) computing—decentralized communication and resource sharing directly between devices—were envisioned early on in the discussions about software systems and networking. In fact, these ideas are mentioned in RFC 1, 'Host Software,' by Steve Crocker, and echoed in Tim Berners-Lee’s vision for the World Wide Web.

However, it was the rise of the file-sharing application Napster in 1999 that catapulted P2P into the public consciousness—not only for its innovative approach to sharing music files for free with strangers but also for the ensuing legal controversies.

The relevance of this architectural style is likely to surge again with increasing discussions on network neutrality, distributed Machine Learning, and distributed social networks.

Choosing the Best Architectural Style for You

When selecting the best architectural style, start by considering the specific business outcomes you aim to achieve. There is no one-size-fits-all approach to building a software system; it always hinges on your particular application. Evaluate the trade-offs of each decision and the potential benefits to your design.

An immutable truth in system design is its inherent mutability and continuous evolution. Always aim to refine and improve your architecture as your organizational needs shift, the IT landscape evolves, and the capabilities of your providers expand.

For a complete deep dive into these architectural style check out “Six Modern Software Architecture Styles”

Real-time Multiplayer Collaboration is a Must in Modern Applications

Vladi Stevanovic — Thu, 14 Mar 2024 08:04:10 +0000

When thinking of modern applications, we have come to expect certain features: global availability, accessibility through web browsers and mobile devices, and a user experience that is both intuitive and efficient …

For those of us who have worked on distributed teams—due to geographic distribution, working preferences, or the size of our organization—the impact of collaborative features on productivity is well understood. That is why our expectations of modern applications extend to: being able to share our work with colleagues, receive immediate feedback without having to switching to another app, and collaborate on projects in real-time.

Various terms have been proposed to describe the shift from single-player to multiplayer tooling, including: “real-time multi-user collaboration”, “multiplayer collaboration”, “deep collaboration” and “collaborative enterprise.”

Regardless of the terminology, it’s undeniable that real-time multiplayer / multi-user collaboration is now table-stakes. The benefits to team alignment, communication and consensus alone are exceptional. When individuals can work together in a shared space, using a common language and framework, productivity increases as collaboration becomes seamless.

Just think of how painful and slow collaboration used to be when everyone worked individually, in silos, on the same project. We would pass a project file back and forth, with our individual additions and changes. And then somebody would have the dubious pleasure of reconciling (if at all possible) all the work of the entire team, and producing the “final_final” version of the document.

Beyond improving team alignment, real-time multi-user collaboration serves as a powerful virality machine for businesses and an efficient monetization strategy. The ability to invite and involve more stakeholders in a project ensures that (1) more people will use your product to drive a “bottoms-up” sales movement, and (2) you will get higher adoption and retention rates within organizations.

It’s not a coincidence that Figma, Miro, Canva, Notion, Google Workspaces, etc. have been so popular and successful in the past few years. And beyond them, many SaaS businesses, even companies that haven’t traditionally thought of themselves as collaboration-first, have embraced this trend.

Real-time Collaboration in Software Development

Developer tools are one of the verticals where real-time multi-user collaboration is particularly a good fit. In fact, it is rapidly becoming a must-have requirement.

Software engineering inherently demands collaboration for coordinating efforts, integrating software components, and ensuring the final product is both cohesive and functional.

Furthermore, organizations are realizing that all aspects of software engineering require a collaborative approach, including system architecture. In fact, the evolution of the Software Architect role from ‘Ivory Tower Architect’ to viewing architecture as a 'team sport', highlights the necessity of diverse input and contributions for a successful system design.

There are many benefits when a team collaboratively engages in designing the system architecture. Most obviously the fact that a team-wide grasp of the system fosters informed decision-making and reduced misunderstandings.

This approach not only leads to a more cohesive final product but also enhances the system's robustness. By understanding the system's structure and dependencies, the engineers can pinpoint optimization opportunities, improving resource efficiency and overall performance.

When evaluating which application features to build, an obvious question to ask is “is there a less effective solution already in place that we could improve upon?” In the case of real-time multi-user collaboration, the question to ask is “are there signs that collaboration is already taking place, albeit inefficiently?”

It is obvious that collaboration around system design is currently happening - therefore making it a prime candidate for the introduction of a tool that leverages real-time multi-user collaboration.

This why when our team built Multiplayer.app - a system design and architecture documentation tool - we made collaboration a fundamental requirement from the outset, integrating it as a core feature of the application. This blog post will delve into our approach to this feature and the solutions we implemented.

Multi-user Collaboration in Practical Terms

When designing Multiplayer we wanted to enable our users to experience fully instant and simultaneous collaboration. This means that every user can edit anything at any time, with all edits being immediately synchronized and any conflicts automatically resolved.

This concretely translates in these feature sets:

(1) Awareness or Presence: These features enable the real-time tracking and display of user status (i.e. avatar stack, live cursors, user in-app location, typing indicators).

(2) State Synchronization: This ensures that all user actions and changes are accurately synchronized and instantly propagated to every user (i.e. live updates, co-editing, undo / redo).

(3) PUB/SUB Messaging: This allows for the efficient delivery of messages to the appropriate user, in real-time (i.e. comments, push notifications)

The implementation of real-time multi-user collaboration presents significant challenges, which have been explored by computer scientists for decades.

Two notable algorithmic solutions have emerged: Operational Transformations (OTs) and Conflict-Free Replicated Data Types (CRDTs).

Of course, it’s also possible to use websockets or, depending on your problem space (and the desired behavior for different states) opt for a custom approach inspired by the traditional algorithmic solutions. For example, you might get inspired by multiple separate CRDTs and use them to create the final data structure that best represents your document (similar to the approach Figma took).

After researching all the various solutions, we opted to use a two fold approach:

Websockets: For simpler features such as the avatar stack or commenting, that don’t require conflict resolution and can have only a single owner, we opted to extend an existing RESTful API and simply broadcast request and response messages to all connected clients using websockets.
CRDTs: For more complex features that require sophisticated conflict resolution due to concurrent inputs from multiple users (e.g. co-editing) we chose to implement a widely-used open-source CRDT implementation called Y.js.

Easiest and Fastest Way to Implement CRDTs

Our investigation identified CRDTs as the optimal solution for conflict-free collaborative features, due to their simplicity, speed, and robustness. In comparison, Operational Transformations (OTs), the technology behind Google Docs, proved overly complex for a startup prioritizing rapid feature deployment.

CRDTs are categorized into two types: operation-based CRDTs (or Commutative Replicated Data Types) and state-based CRDTs (Convergent Replicated Data Types). Both variants ensure strong eventual consistency, meaning that despite temporary connectivity issues or high latency, all connected clients will ultimately converge to a consistent final state.

CRDTs encompass a suite of straightforward algorithms, including last-writer-wins registers, grow-only counters, positive-negative counters, grow-only sets, two-phase sets, last-writer-wins element sets, and sequence CRDTs, to name a few.

Our choice of Y.js was driven by the compatibility its data structures such as documents, maps, and arrays, to conventional JavaScript data types, which facilitated the integration into our application without significant refactoring.

Y.js stood out for several additional reasons:

An extensive array of open-source integrations with code editors, whiteboard apps, and rich text editors
The capability to support any data structure through Y.js Shared Types
Seamless client reconnection without data loss
Network agnosticism
Built-in, user-friendly “awareness” (user presence) features
A large and active community

To illustrate the implementation of Y.js CRDTs in Multiplayer, consider the scenario where two users edit the platform system architecture simultaneously.

While one user (Client 1) relocates a collaboration service within the architecture, another user (Client 2) might be renaming it. Y.js ensures that these concurrent changes merge seamlessly in the final state.

While the integration of Y.js into our platform was largely straightforward, we encountered some notable challenges:

(1) Keeping Track of Order of Elements

Y.js supports arrays, but maintaining the order of elements requires additional effort. A naive approach might involve assigning an integer to represent the order of each element.

However, this method is impractical for long lists: whenever a new element is inserted you have to change the order value of every single element that follows it.

Our solution was to adopt fractional indexing, similar to the method used by Figma. This approach allows for the insertion of an element without the need to adjust the positions of subsequent elements.

To implement fractional indexing effectively, we utilized an arbitrary precision library instead of the standard JavaScript number type, which is a 32-bit floating-point number with limited precision. This choice avoids the precision limitations inherent in the built-in number type, ensuring scalability for lists with frequent insertions.

(2) Supporting Cross-Document Changes

Y.js does not inherently support changes that need to propagate across multiple documents. To accommodate inter-document dependencies and ensure seamless updates, we established connections between various data structures within our application. By monitoring changes in the Y.js document, we could automatically synchronize updates across related documents.

For instance, if a user renames a component from "web-api" to "auth-api" within the platform architecture panel, this change is instantly reflected in all instances where the component is referenced, such as in the component list panel or on the individual component page, without the need for manual refreshing.

It’s Not Just Data Types, There’s System Architecture Too

Although Y.js supports a peer to peer system design, where you don't need a central service, you need to also consider the best system architecture that would serve your business model.

For instance, a critical requirement for our application was the ability to have version control for system architectures. This necessitated the implementation of a snapshotting functionality, which in turn led us to introduce a central 'peer' within our architecture, named the 'collaboration service'.

Leveraging the Y.js library, this service resolves conflicts and provides the definitive source of truth for our data. Specifically, the collaboration service is responsible for:

Providing the most recent version of the document to newly connected clients.
Sharing edits among all active clients to ensure real-time synchronization.
Creating and storing document snapshots for version control.
Controlling additional required actions seamlessly(create links, validate content)

Moreover, to enhance the efficiency and reliability of our collaboration infrastructure, we integrated a directory service cluster. This component is tasked with:

Determining optimal locations for hosting collaboration sessions.
Monitoring active sessions.
Seamlessly transferring sessions as necessary to balance load and optimize performance.

These architectural decisions were instrumental in enabling seamless real-time interactions while accommodating essential features such as version control. However, as with any system architecture, ours is also continuously evolving!

To scale the collaboration service, we plan to decouple the functionalities for which the “collaboration service” is responsible, moving the snapshotting to a dedicated service. We want to move from a stateful to a stateless architecture (possibly leveraging Kafka or RabbitMQ) to share user edits as fast as possible and to ensure continuity of service in case the “collaboration service” goes temporarily down.

Conclusion

To summarize, integrating real-time multi-user collaboration into your application offers three key advantages:

Enhanced User Experience: This translates to a faster 'time to fun' for users, as they can align, communicate, and reach consensus with minimal effort.
Shorter Production Cycles: By ensuring that users have a clear understanding of expectations, responsibilities, and the project roadmap, you can avoid miscommunications and unnecessary revisions. Collaborating in a unified space also minimizes context switching and boosts productivity, leading to a quicker 'time to market'.
Increased Business Revenue: When your tool becomes integral to the workflows of entire teams or organizations, you benefit from higher adoption and retention rates, positively impacting your revenue.

Our teams’ commitment to seamless alignment and real-time visual collaboration not only influenced our name but also catalyzed extensive research and experimentation in developing collaborative features using a lean and open-source-oriented tech stack.

Two key takeaways from our journey are:

Leverage Existing Solutions: There's a wealth of tools available for incorporating real-time collaboration into your app. While we chose Y.js for in-house development, other options like Liveblocks or Ably offer SaaS solutions. Don’t reinvent the wheel!
Prioritize Collaboration from the Beginning (if you can): Integrating real-time collaboration features at a later stage or only to a part of an existing product can be complex and less effective. By considering these features in your initial design phase, you ensure a cohesive user experience and make technological choices that support the ongoing development of these capabilities.

We hope our experiences and insights inspire you to explore how you can integrate similar functionality into your applications to enhance collaboration and productivity.

[Part 1] Delving into Architectural Drift

Vladi Stevanovic — Wed, 13 Mar 2024 18:11:39 +0000

When building a software system, engineers recognize three fundamental truths:

All software has an architecture, whether it is designed and implemented intentionally, or it emerges by coincidence.
System complexity grows over time as requirements shift, use cases evolve, team members come and go, and technologies advance.
Without deliberate management of the system’s evolution, its architecture may stray from its original objectives and blueprint, leading to unintended architectural drift.

Architectural drift can affect any application, irrespective of its initial architectural style or the quality of its original design.

After all, the ease of making changes to a system has significantly increased compared to the past. Gone are the days when you had to phone your hardware rep to order a new server, confirm that there was rack space for it in the data center (i.e. basement), configure it, integrate it into the network, and migrate data into it. Nowadays, a few clicks in a cloud vendor console or a commit to Infrastructure as Code (IaC) can redefine your application’s architecture in mere minutes.

Engineers not only face the challenge of adapting to continuously evolving system architectures but also grapple with the shifting role of software architecture within agile teams and the lack of visibility into the architectural decisions made by other teams.

This leads to a vicious cycle where architectural drift makes the system increasingly difficult to comprehend and modify. Developers find it challenging to implement changes without causing unintended side effects or disrupting existing functionalities, which leads to further architectural drift.

As a result, development cycles lengthen, costs rise, and overall productivity declines.

Understanding the root causes, consequences, and strategies for managing system architecture drift is vital. This blog post aims to provide a comprehensive exploration of architectural drift, including its definition, underlying causes, consequences, and effective mitigation techniques.

The What and Why of System Architecture Drift

System architecture drift falls under the broader category of Architectural Technical Debt, which encompasses all the intentional and unintentional decisions made during the system design process (e.g. architectural style, tech stack, development methodologies, etc.), that result in issues such as reduced maintainability, increased complexity, decreased performance, and scalability challenges.

Specifically, Architectural Drift refers to the gradual deviation of a system’s architectural design from its original or intended architecture due to ad-hoc alterations and additions.

Imagine that you’re building a house designed in the Mediterranean style, complete with characteristic clay tile roofing, stucco walls, and wrought iron balconies. Suppose, partway through, you decide to incorporate a Gothic-style round turret to accommodate your astronomy hobby. Later, to cater to your growing family, you might add a post-modern extension. What began as a cohesive design evolves into a disjointed amalgamation of styles.

This analogy mirrors the reality in software architecture: the system may start with a clean architecture but evolve into a complex tangle of multiple architectural paradigms, inconsistent coding practices, redundant components, and tangled dependencies due to uncoordinated additions and modifications.

There are various reasons behind system architecture drift:

Adapting to Evolving Needs: Architectural adaptations are often intentionally made to align with changing requirements or evolving business needs. Software systems are dynamic entities, and architectural drift can sometimes reflect an organization’s commitment to rapidly delivering new functionalities, meeting customer demands.

Unclear Architectural Governance: Development teams lack a defined architecture, guidelines, or principles to guide their work. This lack of direction can lead to ad-hoc decision-making and improvisation, contributing to architectural drift.

Result of Architectural Technical Debt. Compromises, shortcuts, and errors made during development can have a knock-on effect on other architectural decisions. Examples of ADT issues that influence future choices:

Re-inventing the Wheel: Choosing custom-built components over existing solutions with similar functionality (e.g. building your own persistence library).
Permanent MVPs. A temporary, “bare-bones” solution becoming an integral part of the system’s architectural foundation (e.g. adopting prototypes of a new architecture, immature R&D components, experimental development branches, etc.).
Persistent Workarounds. A temporary workaround, implemented to bypass some architectural constraints, becoming deeply embedded into the architecture.

Inadequate Collaboration. Poor collaboration within and between teams can exacerbate architectural drift. Without a shared understanding or visibility into the overall system architecture and modifications made by other teams, disjointed efforts can lead to increased fragmentation and inconsistency in the system’s architecture.

Architectural drift ultimately builds over time due to a multitude of factors — different business needs, architectural directions, rogue spinoffs — resulting in increased system complexity and creating a less maintainable and cohesive architecture.

What's Next

For more about system architecture drift check out these next articles:

101 on Architectural Technical Debt
[Part 2] Architectural Drift in Real Life Systems
[Part 3] The Temptation to Ignore Architecture Drift
[Part 4] Effective Measures to Control System Architecture Drift

Thank you for reading! 💜