On Programming, Software Architecture, and Sociotechnical Systems

Usually, in an event-driven architecture, events are emitted by one service and listened to by many (1:n). But what if it's the other way around? If one service needs to listen to events from many other services?

Given that events play such a central role in event-driven architecture, there’s an astonishing lack of agreement on what should be contained in an event. This may be rooted in the fact that, depending on your perspective, events fulfill different purposes.

An opportunity for everyone to make a little self-test. Do you believe any of these five statements? If so, don't worry, you're not the only one, I've come across them many times. I'm very convinced they're untrue, though. This is my little attempt to better a shared understanding of some properties of event-driven architecture.

There’s much uncertainty and doubt (and maybe even fear?) around event-driven architecture. One example is the belief that it’s irrelevant for REST APIs, as using HTTP verbs is quite clearly not event-driven. But behold - you don’t always have to go all-in to win.

There are a few ways for services to communicate that can be rightfully classified as asynchronous. But they have very different characteristics. Let's have a look at them and their impact on the overall system structure.

The Java Virtual Machine is not limited to running programs written in the Java programming language. There are many other compilers that output Java bytecode. Some of these languages have so far remained exotic. Others have found a large following, for example Groovy, Clojure, Scala and Kotlin. Now, with Flix, another language, that brings some fresh approaches to the JVM, has entered the scene.

Project Loom is an experimental version of the JDK. It extends Java with virtual threads that allow lightweight concurrency.

“Events! Events everywhere!” - or so it seems. This isn’t a bad thing, not at all: Event-driven Architecture can help to make microservice architectures scalable and resilient. But there are different patterns at play that we need to distinguish. And not everything is an event. An attempt for clarification.

Almost regularly I see Scala code where people program in a sequential, synchronous style and integrate an asynchronous I/O call by waiting for its completion with Await.result. But you really shouldn’t.

Java is skiing. Scala is snowboarding. Kotlin is carving skis.

In my first blog post, '10 Scala Features Most Java Developers Love', I assembled a top 10 list of Scala features I wouldn't want to miss, and that I found more or less universally liked in conversations with other Java developers. Here are 10 more that would have deserved to also be on the list.

When you attempt to build reactive systems coming from the world of Java web and enterprise development, you’ll stumble across some fundamental differences and might wish someone had told you earlier. Unless you read this blog post, of course, because I’m going to let you in on four things you should know.

Some Java developers seem to be intimidated by Scala. They get hung up on some possibly rather obscure feature, and from that conclude that the language must be a complicated maze you can only get lost in. There are so many features in Scala, though, that are so easily accessible, and that really just make the developer’s life easier. This is my list of 10 features that are easy to understand and use, yet very powerful.