Architecture on Micha Kops' Tech Notes

Message-Driven Architecture Across Multiple Teams

Fri, 05 Sep 2025 00:00:00 +0200

Whenever I start planning a new message-driven architecture that spans several software teams, I quickly realize how many moving parts there are.

To keep my head clear, I’ve put together a personal checklist of things I always try to cover.

It’s not meant to be a formal rulebook, but more of a practical reminder of what usually makes the difference between smooth collaboration and endless headaches.

Figure 1. Message Driven Architecture Article Cover Image

Modeling AWS Structures with PlantUML and AsciiDoc

Tue, 08 Nov 2022 00:00:00 +0100

The AWS shapes are included in the PlantUML stdlib .. simply include them as shown here:

example.puml

@startuml
!include <awslib/AWSCommon>
!include <awslib/Analytics/ManagedStreamingforKafka>
!include <awslib/Database/RDS>
!include <awslib/General/Users>
!include <awslib/General/InternetGateway>

!include <kubernetes/k8s-sprites-labeled-25pct>

skinparam linetype ortho

title "AWS Context Diagram"


package "EKS Kubernetes Cluster" as eks_cluster {
    component "<$pod>\napp1" as pod1
    component "<$pod>\napp2" as pod2
}

ManagedStreamingforKafka(kafka_pod, "Amazon MSK", "Apache Kafka")

RDS(pg_rds, "PostgreSQL", "Sample Schema")


Users(users, "AppUsers","editors, admins")

InternetGateway(igw1, "Customer Gateway", "Customer access to internal services")

users -> igw1
igw1 --> pod1
igw1 --> pod2
pod1 --> pg_rds
pod1 --> kafka_pod
pod2 --> pg_rds
pod2 --> kafka_pod

@enduml

C4 Modeling with PlantUML and AsciiDoc

Tue, 01 Nov 2022 00:00:00 +0100

C4 models allow us to visualize software architecture by decomposition in containers and components.

Viewpoints are organized in hierarchical levels:

Context Diagrams (Level 1)
Container Diagrams (Level 2)
Component Diagrams (Level 3)
Code Diagrams (Level 4)

C4-PlantUML offers a variety of macros and stereotypes that make modeling fun.

An example in PlantUML:

sample.puml

@startuml
!include <c4/C4_Context.puml>
!include <c4/C4_Container.puml>

left to right direction

Person(user, "User")

System_Ext(auth, "AuthService", "Provides authentication and authorization via OIDC")

System_Boundary(zone1, "Some system boundary") {


    System(lb, "Load Balancer")

    System_Boundary(az, "App Cluster") {
        System(app, "App Servers") {
            Container(app1, "App1", "Docker", "Does stuff")
            Container(app2, "App1", "Docker", "Does stuff")

            ContainerDb(dbSess, "Session DB", "Redis")
            ContainerDb(db1, "RBMS 1", "AWS RDS Postgres")
            ContainerDb(db2, "RBMS 2", "AWS RDS Postgres")

            ' both app servers sync sessions via redis
            Rel(app1, dbSess, "Uses", "Sync Session")
            Rel(app2, dbSess, "Uses", "Sync Session")

            ' both app servers persist data in RDBMS
            Rel(app1, db1, "Uses", "Persist/query relational data")
            Rel(app2, db2, "Uses", "Persist/query relational data")
        }
    }
}

Rel(user, lb, "call")
Rel(lb, app1, "delegate")
Rel(lb, app2, "delegate")
Rel(app1, auth, "Verify", "User auth")
Rel(app2, auth, "Verify", "User auth")

SHOW_FLOATING_LEGEND()

@enduml

Testing Java Applications for Resilience by Simulating Network Problems with Toxiproxy, JUnit and the Docker Maven Plugin

Sun, 29 Jul 2018 00:00:00 +0200

When implementing distributed systems, client-server architectures and simple applications with network related functionalities, everything is fine when we’re in the development or in the testing stage because the network is reliable and the communicating systems are not as stressed as they are in production.

But to sleep well we want to validate how resilient we have implemented our systems, how they behave when the network fails, the latency rises, the bandwidth is limited, connections time out and so on.

Managing Architecture Decision Records with ADR-Tools

Sun, 27 May 2018 00:00:00 +0200

Every software project includes a set of architecture decisions defining boundaries and constraints for further design and implementation.

It’s important to document those decisions somehow or else a development team might not know which decisions where made and with which assumptions.

Or they know the decision but are missing the context and the consequences and therefore decisions are blindly accepted or blindly changed.

In the following short tutorial I will show how to structure architecture decisions in so called Architecture Decision Records and how to manage them with a simple tool named ADR-Tools.

Software Architecture Exploration and Validation with jqAssistant, Neo4j and Cypher

Sun, 31 Dec 2017 00:00:00 +0100

I have written about other software system analyzing and validation tools before but today I would like to introduce a new tool named jqAssistant that supports software architects, developers and analysts in a variety of tasks like analyzing given structures, validating architectural or quality constraints and generating reports.

Therefore jqAssistant analyzes given projects or artifacts and stores the gathered information – that is enriched by a variety of existing plugin-ins – in a Neo4j graph database.

Assuring Architectural Rules with ArchUnit

Mon, 03 Jul 2017 00:00:00 +0200

Maintaining architecture rules and constraints for a specific software project or an application is not easy as textual documentation is easily forgotten after a while and hard to verify.

ArchUnit is a testing library that allows developers and software architects to write down such rules as executable tests that may be run by the development teams and the integration servers.

In the following article I will demonstrate the basic features of this library by applying rules and constraints to an existing application.

Resilient Architecture in Practice – Circuit Breakers for Java: Failsafe, Javaslang, Hystrix and Vert.x

Tue, 14 Feb 2017 00:00:00 +0100

When dealing with remote services or APIs there is always the risk of latency issues, failures or connection losses. The worst thing to happen is when the remote service is down and our application hangs until the underlying protocol’s (e.g. TCP) connection timeout is reached and we’re receiving an exception. Until this moment is reached, our application might hang, memory is allocated for threads or bound objects and at last, our continuous requests might prevent the remote system from recovering.