Mourjo Sen
Staff Software Engineer, Booking.com
Amsterdam, The Netherlands
Actions
I am a professional software engineer for over ten years now, I have worked with object oriented and functional programming on large-scale distributed systems. I find joy in speaking and writing about software engineering. Some of my articles and blogs are available here: https://mourjo.me
Links
Area of Expertise
Topics
Solving Architectural Entropy With Runnable Diagrams
"Software architecture does not age gracefully. Software architecture degrades in direct proportion to the number of changes made to the software"
- Architecture of Open Source Applications, Berkley DB.
This observation is painfully familiar to anyone building domain-driven systems at scale. We often begin with carefully designed microservices and a shared understanding of the domain, but as new requirements arrive, teams optimize for delivery speed and as a result, architectural shortcuts creep in. Over time, the original design intent fades and it becomes increasingly difficult to understand how it all works.
In a typical engineering discussion, complex ideas are explained using diagrams and visual cues. Architectural diagrams are a central component in today's engineers' arsenal because of this universal appeal -- whether it be a new joiner or the veteran, diagrams provide instant clarity that code alone cannot.
Unfortunately, most diagrams fall out of date as the system changes. But what if diagrams were not a documentation of a past version of the system, but were the definition of it?
Instead of merely describing interactions between microservices, Business Process Model and Notation (BPMN) uses a visual language for defining how microservices interact with one another to solve business requirements. The same diagram is understood by humans and executed by machines, creating a powerful synergy between architecture, implementation, and business intent.
By introducing an explicit orchestration layer, BPMN brings proven composition patterns. Instead of bespoke in-house implementations, a unified orchestration layer prevents domain driven services from drifting from their original design intent.
With executable diagrams, we can finally tame the problem of architectural entropy that slowly creeps in, even in well intended design. It makes the system easier to understand and faster to evolve, while bringing different factions of the organization closer.
Property Based Testing to Preserve Invariants
Property based testing (PBT) is a method of testing a system’s invariants – qualities or properties that must not change irrespective of complex interactions.
Testing aims to ensure our source code meets the product’s expectation or “acceptance criteria”.
Usually test cases enumerate examples that prove the criteria. But examples are merely discretization of the criteria: a number of things can necessitate us to re-enumerate the examples:
- Change in product specification
- New usage patterns
- Source code refactoring
- etc
PBT instead tests the criteria itself and generates the examples on its own. The term "invariant" conveys the fundamental unchanging nature of the properties we want to test:
- In a sorted list, every number is less than or equal to the next number
- A person can only be in one meeting at a time
- Account transfers do not change the total sum of money in a bank
PBT tests the properties that organically define the system. I will show how to write property based tests that bring the product and the test suite closer.
What Flow Metrics Teaches Us About Designing Resilient Systems
Flow metrics, often used in agile methodology, can teach us how to differentiate "goodput" (work valuable to the customer) from "throughput" (total work done by the system). In this talk I will go over what flow metrics are and what we can learn from it while designing resilient scalable systems.
In a fast paced development team, it is often difficult to identify blockers in real time. This impacts the ability of the team to deliver value to its customers. A system of consistent and meaningful monitoring of key metrics, such as flow metrics, can help address such blind spots ultimately delivering value to customers in a sustainable manner.
Flow metrics comprises the following
1. Velocity: How much work is done by a team per unit time?
2. Time: How much time something takes to get completed?
3. Efficiency: How much time did the team have to wait for something else to be done?
4. Load: How many items remain open in the task list at the same time?
In essence, flow metrics offer a holistic measure of the performance of software development life-cycle. Specifically, it benchmarks the ability of a software development team to deliver on business and technical requests - much like the systems they build which are meant to deliver on incoming requests efficiently.
Inspired from flow metrics, we can apply a similar set of metrics on our system:
1. Velocity or throughput: How many requests per second do we handle?
2. Time: How much time did we take to process a request?
3. Efficiency: Did a downstream dependency be the reason for our outage?
4. Load: If there are too many requests coming in, can we detect it?
In this talk I will focus on two things
- Why flow metrics matters to live applications at scale - this will focus on understanding the foundations of Flow metrics
- How flow metrics can help design better systems - this will focus on designing a system of measuring actionable metrics (for example, too much load can cause a cascading failure across multiple systems that are dependent on one system)
techcamp 2025 Sessionize Event
Monster Scale Summit 2025 Sessionize Event
Mourjo Sen
Staff Software Engineer, Booking.com
Amsterdam, The Netherlands
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top