Architecting a scalable and dynamic system without caching is explained by Peter Morgan, head of engineering for the sports betting company William Hill. The values of the bets on sporting events change constantly. No data can be cached; all system values must be current. Distributed Erlang processes model domain objects which instantly recalculate system values based on data streams from Kafka.
A key problem with the whole Reactive space and why it’s so hard to understand is the vocabulary with all the terms and lots of different interpretations of what it means, Peter Ledbrook claims and also a reason for why he decided to work out what it’s all about and sharing his knowledge in a presentation.
Yahoo! has benchmarked three of the main stream processing frameworks: Apache Flink, Spark and Storm.
Storing events in a relational database and creating the event identity as a globally unique and sequentially increasing number is an important and maybe uncommon decision when working with an event-sourced Command Query Responsibility Segregation (CQRS) system Konrad Garus writes in three blog posts describing his experiences from a recent project building a system of relatively low scale.
Modern software increasingly operates on data in near real-time. There is business value in sub-second responses to changing information and stream processing is one way to help turn data into knowledge as fast as possible, Kevin Webber explains in an introduction to Reactive Streams.
Eventual consistency is a design approach for improving scalability and performance. Domain events, a tactical element in Domain-Driven Design (DDD), can help in facilitating eventual consistency, Florin Preda and Mike Mogosanu writes in separate blog posts, each describing the advantages achievable.
Command Query Responsibility Segregation (CQRS) is the starting point of a change that will have a profound impact on system architecture, Dino Esposito claims in three articles in MSDN Magazine. It’s the first step in an evolution transitioning software architects from the idea of “models-to-persist” to the idea of “events-to-log” and about event-based data instead of data snapshots.
Looking at Command Query Responsibility Segregation (CQRS) in a larger architectural context there are other architectural styles available. There are database technologies solving the same problems but in a simpler way, Udi Dahan states looking into ways of approaching CQRS. There is also a way that fulfils a lot of the CQRS goals but with fewer moving parts when CQRS is really needed.
To make microservices awesome Domain-Driven Design (DDD) is needed, the same mistakes made 5-10 years ago and solved by DDD are made again in the context of microservices, David Dawson claimed in his presentation at this year’s DDD Exchange conference in London.
Improving on his understanding of the architecture and patterns involved in Command Query Responsibility Segregation (CQRS), Sacha Barber has created a complete CQRS demo application including event sourcing and an article with a cross examination of the inner workings.
Today’s applications are commonly unnecessarily complex or slow because of not using Command Query Responsibility Segregation (CQRS), Gabriel Schenker claims while stating he believes CQRS to be one of the most useful architectural patterns when used in the context of complex Line of Business (LOB) applications.
A service is a logical construct owning a business capability and made up of internal autonomous components or microservices that together fulfil the responsibilities of the service, Jeppe Cramon suggests continuing a previous series of blog posts clarifying his view on building services around business capabilities and bounded contexts.
Structuring data as a stream of events is an idea appearing in many areas and is the ideal way of storing data. Aggregating a read model from these events is an ideal way to present data to a user, Martin Kleppmann claims explains when describing the fundamental ideas behind Stream Processing, Event Sourcing and Complex Event Processing (CEP).
The World Wide Web Consortium (W3C) has published the Pointer Events standard as a recommendation for wide adoption, but its future is in doubt as Apple and Google are refusing to implement it.
The Chromium team announced back in August that Google is no longer working on implementing Pointer Events in Chrome in order to focus on Touch Events. Now they have given control to the Pointer Events polyfill library to jQuery which is hoping to “drive developer adoption of this unified event system” and eventually see “all browsers implement this standard natively.”