Many big technology companies like Netflix, Uber and Spotify have moved from a monolithic architecture to a microservices architecture in order to successfully build and run complex systems at a massive scale.

Event-driven architectures are becoming increasingly popular in the microservice space due to the scalability potential as well as it’s adaptability. It’s a powerful architecture, but it does come with its challenges.

In order to help you determine whether it’s an interesting architecture for your next technology endeavor I’ve decided to write an in-depth series of blogs, called ‘the engineers guide to event-driven architectures’, that will cover topics like:

• Different types of event-driven architectures and their…

The hype creates a dynamic of inflated expectations and excitement with business representatives and software engineers alike. In companies and teams where decision pushing is commonplace this often leads to rushed decisions, which likely ends in frustration and disappointment.

Business representatives, software engineers and other technical specialists should be freely exchanging ideas, discussing risks and doubts as well as challenging each other with strong mutual respect. Creating this culture takes effort, a sense of personal responsibility and proactiveness from all involved. …

At the beginning of the year, before the human malware breakout, an Italian engineer joined our team straight from university. She has a superpower. Randomness. Along the way I realized just how important randomness is in learning and building a team. Unfortunately, working fully remote is killing that randomness and with it a lot of benefits.

Why randomness matters

Being in a new country, a new company and having to rapidly prove yourself as an engineer in a complex environment with established teams. I can only imagine the roller-coaster that must have been.

When it comes to onboarding and learning, we rely on structure. We have a fixed set of onboarding content about the project, ways of working and the technology. There are fixed points in the development process like refinement, story sizing and pull requests where a lot of learning takes place. …

Let’s face it. Java is an ancient language that is struggling to stay relevant but is not suited for containerized microservices due to its big resource footprint and limited concurrency. Java is trying to catch-up, but was clearly late to the party. So late in fact that everyone already left for the afterparty. Where Java wasn’t invited to. The language feels old with its terribly verbose syntax. And engineers no longer care about learning Java.

Big technology companies like Netflix still use Java in their system, but they also use Node, Python, Ruby and Go. It’s a similar story over at Uber. It’s common for modern distributed microservice architectures to leverage multiple languages, also called polyglot, and pick those languages based on their unique ability to address a particular challenge that the system has to deal with. In a distributed world, there is much less need for a general-purpose language like Java that tries to do everything, lacks focus and doesn’t have a clear purpose or identity. …

There is a lot of things I like about Java, but its dated implementation of threads is challenging to work with when developing high-traffic microservices. Java threads are implemented as operating system processes, which makes them heavyweight in two ways: switching between threads is slow and their memory consumption is high.

Combine those heavyweight Java threads with the thread-per-request model that servlet based microservices use, and we arrived at the performance challenge for microservices in Java that that are deployed in high-traffic scenarios. Let’s explore why this presents challenges, and what the potential solutions are.

The thread-per-request model of Tomcat

The majority of Java microservices that expose an API are built with Spring Boot in combination with the Spring Boot Starter Web. This starter uses Apache Tomcat as the default embedded servlet container to capture incoming requests and Spring MVC to route those requests and build the API endpoints. …

Software engineering, as a culture, seems determined to sell each other on solutions based purely on some benefits, without consideration of context, complexity and cost. If you are not using complicated architecture pattern X or infinitely scalable message broker Y you are doing microservices wrong. So, contrariety to popular believe, engineers are better at delivering (one-sided) sales pitches than most think. All jokes aside, it’s problematic. It leads to over-engineered microservice architectures and it completely disregards the trade-offs, which becomes problematic for engineering teams who are not prepared to deal with those trade-offs.

A good example of this is the combination of the Event Sourcing and the Command Query Responsibility Segregation (CQRS) architecture patterns. Often presented as the silver bullet for solving many robustness, performance and decentralized data challenges that microservices architectures face. Yet there is hardly any talk on the ton of hidden complexity with these patterns. So, how do these patterns handle robustness, performance and decentralized data challenges? …