Day three of the 19th annual QCon London conference took place on April 9th, 2025, at the Queen Elizabeth II Conference Centre in London, England. Key takeaways included: a dedicated leader owns the vision, but the human experience can be tense; CRDTs are useful, but are very subtle things as models cannot be correctly set; and to betray trust in the relationship between security and architecture means to betray both.
What follows is a summary of the keynote address and highlighted presentations.
Keynote Address: Advanced Message Queuing Politics
John O’Hara, Father of AMQP, Venture Partner at Fidelity and Founder of Taskize, presented his keynote address entitled, Advanced Message Queuing Politics.
O’Hara started his presentation with a story about a bank that developed a message-oriented middleware system, ultimately selling the software to an “enterprising chap” who started a company based on that software. That was the business case for AMQP. Message Oriented Middleware is a managed message delivery between computer systems.
By the 1990s, middleware was considered arcane to keep up with the scale at which banks had been operating. The banks would often write their own middleware. By 2002, there were a number of banks that had their own middleware, with some that ultimately became overpriced commercial products.
When it comes to managing the lines between various entities, O’Hara stated that “inter-business and intra-system connections are a major source of complexity and cost.“
Today, we have an AMQP specification standard with seven implementations. All clients can communicate with all servers.
Creating a universal standard can be challenging. In 2002, there were 14 standards, and O’Hara stated that we are all too familiar with this situation.
Despite being released in October 2011, the AMQP 1.0 protocol still remains today’s standard. As O’Hara stated, his presentation is a story of people, visions, passions, friends and competitors, so he described the details on how the AMQP standard had evolved.
In 2003, AMQP was created to: solve the business problem; commodize messaging; make it open-source; and provide a standard for all messaging. O’Hara maintained that it was expensive not to have standards.
Well-known implementations such as IBM MQ (2004) ActiveMQ (2004), RabbitMQ (2007) and Apache Qpid started to emerge since the creation of AMQP. Even the Department of Homeland Security decided to standardize custom operations on AMQP.
Today, AMQP is ISO-certified, under ISO-19464, and implementations of AMQP processes 10 trillions messages per day.
O’Hara concluded his presentation on what he learned from creating AMQP. First, it’s People where a dedicated leader owns the vision. O’Hara didn’t anticipate how intense the human experience would be. Second, it’s Hygiene where everyone needs a business case and to find a way to secure resources. Third, it’s thorough Specifications with mechanisms that provide extensibility. O’Hara stated that the lack of compatibility can be fatal. And finally, it’s Products that provide a balance between users and vendors.
More details from this keynote may be found in this InfoQ news story.
Highlighted Presentations: How to Build a Database Without a Server | Security and Architecture: To Betray One Is To Destroy Both
How to Build a Database Without a Server was presented by Alex Seaton, Staff Engineer at ArcticDB.
Seaton started his presentation by introducing a serverless database through multiple definitions. In general, a serverless database adjusts database capacity based on the demands of an application. Other definitions may be found from MongoDB and Cockroach Labs.
Using ArcticDB and a combination of Python and C++, Seaton focused on the software library and object storage with code examples on how to execute creating a database and querying for stock information.
Object storage consists of a structure as a tree of objects using the same file format. Only the very top layer is mutable. In terms of performance, processing in the native layer (C++) and mapping to Python can be expensive.
Even with the simplest approach to managing the global state, there are still problems. Clock drift is real and can easily be tens of seconds. Seaton suggested using either the system clock or the storage clock. The system clock suffers from drift, and the storage clock suffers from latency effects.
Seaton introduced the Conflict-Free Replicated Data Type (CRDT), defined as any replica that can be updated without coordination with inconsistencies that are automatically resolved. They must be convergent to the same state and => operations must be commutative. Examples of some known CRDTs include: a Grow-Only Set (G-Set), a set that does not allow data to be deleted; a Two-Phase Set (2P-Set), a G-Set that allows data to be deleted; a Last-Write-Wins-Element-Set (LWW-Element-Set), a 2P-Set with “add sets” and “remove sets” with timestamps for the data; and an Observed-Remove Set (OR-Set), a LWW-Element-Set with unique tags instead of timestamps. For managing the global state, Seaton maintained that we should respect the consistency of the LWW-Element-Set.
After demonstrating their new approach using CRDTs, Seaton explained that there are practical problems with: garbage collection, such that there is an accumulation of tiny objects; and compaction, where there is a need to compact while keeping a consistent view for clients.
Seaton also discussed distributed locking in terms of transactions, garbage collection and compaction.
In closing, Seaton provided these key takeaways: object storage is consistently improving (improved concurrency models are now possible); distributed locking is subtle; it is possible to build a useful system, but be aware that clocks don’t act like clocks, sets don’t act like sets and locks do not provide mutual exclusion; and CRDTs are useful, but are very subtle things as models cannot be correctly set.
Security and Architecture: To Betray One Is To Destroy Both was presented by Shana Dacres-Lawrence, Senior Principal Architect at 6point6 and Founder of ArchitectHer.
Dacres-Lawrence started her presentation with a definition of Betrayal as “the breaking or violation of a presumptive contract, trust, or confidence.” For security and architecture, she tailored this definition as “compromising the foundation and trust upon which resilient systems are built.“
From the early days to today, the relationship between security and architecture has evolved from individual silos to one that is more collaborative. But, as Dacres-Lawrence warned, there is still betrayal. To betray one of these means to destroy both.
There are three types of betrayal: Physical (structural weakness), Emotional (assumed loyalty) and Trust (assumed trust). Dacres-Lawrence explored all three types of betrayals and discussed these five defense strategies: Open Communication, Tools and Technology, Automation, Hands-On Validation and Collaborative Culture.
Dacres-Lawrence concluded with five key takeaways: consistency builds trust; adopt a “shift-left” approach; be intentional, not transactional; it’s not possible to test every scenario, but you will have to react; security should guide architecture, but architecture must also shape security.
