feat: 14-08-2026 release — blip rewrites assigned to Moritz

radar/2022-05-17/event-driven-architecture.md

@@ -12,5 +12,4 @@ architecture style](https://docs.microsoft.com/en-us/azure/architecture/guide/ar
 - Real-time processing with minimum time lag.
 - Complex event processing, such as pattern matching or aggregation over time windows.
 - High volume and high velocity of data, such as IoT.
-  Be aware of the complexities and potential pitfalls involved when adopting this architecture. When
-  using Even-Driven Architectures consider using Event Sourcing.
+  Be aware of the complexities and potential pitfalls involved when adopting this architecture.

radar/2023-08-01/bdd.md

@@ -1,18 +1,16 @@
 ---
-title: "BDD with Gherkin, Cucumber"
+title: "BDD with Gherkin"
 ring: adopt
 quadrant: methods-and-patterns
 featured: true
 ---
 
 Behavior-Driven Development (BDD) is a collaborative approach to software development that bridges the communication gap between business and IT. BDD helps teams focus on delivering features that truly matter by emphasizing the behavior of an application from the end user's perspective.
 
-[Gherkin](https://cucumber.io/docs/gherkin/) is Cucumber's language to define test cases. It's designed to be easy to read and lets you write scripts in a natural language style.
-
-[Cucumber](https://cucumber.io/) is a tool that supports BDD. It reads Gherkin documents and validates that the code performs as expected.
+[Gherkin](https://cucumber.io/docs/gherkin/) is the language used to define test cases. It's designed to be easy to read and lets you write scripts in a natural language style.
 
 [Playwright](/tools/playwright) is a powerful tool for end-to-end testing that complements BDD approaches. With support for multiple browsers, headless testing, and API controls, Playwright offers robust testing capabilities for both simple and complex applications.
 
-Adopting BDD, Gherkin, Cucumber and [Playwright](/tools/playwright) in our workflow allows for a clear understanding and discussion of requirements across the team, including non-technical stakeholders. This fosters collaboration and helps prevent miscommunication. Automated testing through Gherkin, Cucumber and Playwright also encourages the development of more robust, bug-free software.
+Adopting BDD, Gherkin and [Playwright](/tools/playwright) in our workflow allows for a clear understanding and discussion of requirements across the team, including non-technical stakeholders. This fosters collaboration and helps prevent miscommunication. Automated testing through Gherkin and Playwright also encourages the development of more robust, bug-free software.
 
 However, BDD is not a one-size-fits-all solution. It works best when the team is committed to the collaborative approach and when complex business rules need to be understood by all stakeholders.

radar/2026-08-14/bdd.md

@@ -0,0 +1,14 @@
+---
+title: "BDD"
+ring: adopt
+quadrant: methods-and-patterns
+featured: true
+---
+
+Behaviour-Driven Development (BDD) is a collaborative approach to software development that bridges the communication gap between business and IT. It keeps teams focused on the behaviour that matters to the people using the software, described from their perspective rather than from the implementation's.
+
+The value of BDD is in the conversation. Writing scenarios together with business stakeholders surfaces disagreement about requirements early, while it is still cheap to resolve. The automated tests that follow are a by-product of that shared understanding, not the point of it.
+
+We write those scenarios in Gherkin, whose Given/When/Then structure is deliberately close to natural language. A scenario stays readable for non-technical stakeholders while remaining precise enough to execute.
+
+BDD is not a one-size-fits-all solution. It works best when the team is genuinely committed to the collaborative approach and when complex business rules need to be understood by everyone involved. Where the requirements are simple, or where the only readers are engineers, the ceremony costs more than it returns.

radar/2026-08-14/databricks.md

@@ -0,0 +1,22 @@
+---
+title: "Databricks"
+ring: adopt
+quadrant: tools
+featured: true
+---
+
+[Databricks](https://www.databricks.com/) is a unified analytics platform that brings data engineering, data science and business analytics into a single workspace. Built by the original creators of Apache Spark, it covers large-scale data processing, machine learning workflows and real-time analytics.
+
+We have extensive Databricks knowledge in house, which is why it moves to adopt. It is also an established choice among our clients, so a good part of this work is joining teams where Databricks is already running and helping them get more out of it.
+
+### Considerations
+
+- **Vendor lock-in:** Databricks is a commercial platform. Pipelines written against its proprietary features are not trivially portable, and both cost and roadmap sit with a single vendor.
+
+- **US cloud provider dependency:** Databricks runs on the US hyperscalers. For clients with digital sovereignty requirements that dependency has to be weighed explicitly — see [European Sovereign Cloud](/platforms-and-operations/european-sovereign-cloud).
+
+### Alternatives
+
+Databricks is not the only thing we offer. We also have extensive knowledge of open source lakehouse setups, and for our own projects that is what we prefer: it avoids the lock-in and the sovereignty questions, at the cost of assembling and operating more of the stack ourselves.
+
+For client work we evaluate which of the two is the better fit — what the client already runs, the engineering capacity available to operate it, and the budget all weigh in. Neither is the default answer.

radar/2026-08-14/event-driven-architecture.md

@@ -0,0 +1,12 @@
+---
+title: "Event-driven Architecture"
+ring: adopt
+quadrant: methods-and-patterns
+featured: true
+---
+
+Event-driven architecture is less a technology choice than a way of thinking about systems. Rather than components calling each other to make things happen, they publish facts about what has happened, and other components decide for themselves what to do with them.
+
+We use this approach, and we use it deliberately. It is not free: asynchronous flows are harder to follow than a call stack, delivery is typically at-least-once so consumers have to be idempotent, eventual consistency has to be a decision rather than a surprise, and debugging spans several components, which means tracing has to be in place from the start rather than added once something goes wrong.
+
+As with any architecture, the right answer is the one that fits the problem. Event-driven is one of the approaches we reach for, not a default we apply everywhere.

radar/2026-08-14/graphql.md

@@ -0,0 +1,14 @@
+---
+title: "GraphQL"
+ring: hold
+quadrant: languages-and-frameworks
+featured: true
+---
+
+We have moved [GraphQL](https://graphql.org/) to hold.
+
+We have used GraphQL in a number of projects and found that in our context it tends to create more problems than it solves. The added complexity in caching, authorisation and schema governance has not paid off against the flexibility it gives us.
+
+Hold does not mean we have stopped. We still actively run GraphQL in production on a current project and keep the skills to do so, so we can support clients who already have it or who specifically need it. What it does mean is that we would not choose GraphQL again for a new project. There we prefer REST for frontend-backend integration.
+
+This is not a judgement on GraphQL as a technology. It is a judgement on how well it fits the kind of solutions we typically build.

radar/2026-08-14/kubernetes.md

@@ -0,0 +1,16 @@
+---
+title: "Kubernetes"
+ring: adopt
+quadrant: tools
+featured: true
+---
+
+Adopting [Kubernetes](https://kubernetes.io/) starts with something more basic: we containerise the stack. Containers are how we run software during development and how we ship it to every environment beyond that, which keeps what a developer runs locally close to what actually goes to production.
+
+How much orchestration a solution needs on top of that varies, and we work across the whole range:
+
+- **Self-hosted Kubernetes**, where a client needs full control over the cluster or has to run on their own infrastructure.
+- **Managed Kubernetes**, where most of our solutions land. The declarative model and the ecosystem around it, without the burden of operating the control plane ourselves.
+- **Serverless containers on managed platforms**, where a solution does not need a cluster at all and the platform scales containers directly.
+
+A mature managed Kubernetes offering is one of our criteria when assessing [European Sovereign Cloud](/platforms-and-operations/european-sovereign-cloud) providers, because it is a large part of what keeps workloads portable between them.

radar/2026-08-14/redis.md

@@ -0,0 +1,12 @@
+---
+title: "Valkey / Redis"
+ring: adopt
+quadrant: platforms-and-operations
+featured: true
+---
+
+For new solutions we now prefer [Valkey](https://valkey.io/) over Redis.
+
+Valkey is the Linux Foundation fork created after Redis moved away from an open source licence, and we think it is now the better of the two: development has been more active, the performance work has gone further, and its governance is genuinely open. It is API-compatible with Redis, so existing clients, libraries and tooling continue to work, and several cloud providers now offer it as their default.
+
+[Redis](https://redis.io/) remains a solid choice and we are happy to use it where a client prefers or requires it, or where it is already running.

radar/2026-08-14/tanstack-query.md

@@ -0,0 +1,14 @@
+---
+title: "TanStack Query"
+ring: adopt
+quadrant: languages-and-frameworks
+featured: true
+---
+
+[TanStack Query](https://tanstack.com/query/) _(formerly known as React Query)_ is hands down one of the best ways to handle queries and application state in JavaScript and TypeScript applications, and it remains our preferred choice for it.
+
+It takes care of fetching, caching, background revalidation, deduplication of in-flight requests and invalidation. That removes a whole category of hand-rolled code that used to end up in every project, along with the bugs that came with it.
+
+Despite the old name, TanStack Query is no longer React-specific. It is built on a framework-agnostic core with adapters for the other major frontend frameworks, so the same approach and most of the same mental model carry across the frontend stacks we work in.
+
+The rest of the [TanStack](https://tanstack.com/) family is worth knowing too. Libraries such as TanStack Table, Router, Form and Virtual are of the same quality and share the same design philosophy, and we use them where they fit.