I have a tendency to rush toward implementation because it feels like progress. By default, my brain seems to reward resolution more than accuracy. But clarity without correctness is false progress. At least in my case, good outcomes require tolerating ambiguity longer than feels comfortable.

Morning-shower-thinking: Problems are socially constructed, solutions are technologically mediated, and both are locked in a continuous feedback loop that reshapes society itself.

Episode 4 of Scalable Modeling is live and it’s the final one. We turn the conceptual and spatial models into running code and show how Santa’s wish management system is implemented directly from the model. 🎥 youtu.be/EhCwwz6EAyI 💻 github.com/roikonen/wis... Happy holidays 🎄✨

Scalable Modeling: Implementing Growth-ready Systems

YouTube video by Scalable Modeling

youtu.be

Episode 3 of Scalable Modeling is live. We convert the temporal model into a spatial model and define where state lives and how parts connect. Episode 4 will convert this model into an actual implementation. Watch: youtu.be/bRsY08pnb6U

Scalable Modeling: How to do spatial modeling?

YouTube video by Scalable Modeling

youtu.be

Episode 2 of Scalable Modeling is live. We build the temporal model and map how the system behaves over time which sets the stage for spatial modeling in the next episode. Watch: youtu.be/kC0KmjRq0yk

Our first Scalable Modeling video podcast episode is live. I sat down with Jose Hidalgo to talk about the background of the approach, the problems it solves and the role of events in building systems that stay scalable and evolvable. Watch it here: youtu.be/gLB4ghyie24

Scalable Modeling: Why & What?

YouTube video by Scalable Modeling

youtu.be

The Integrity Chain: Guardians of Distributed Systems roikonen.github.io/scalablemode...

There’s a fallacy called Object Bias: the fixation on individual things at the expense of actions and the larger context. Rather than merely editing objects, one should attend to actions and meaningful corrections. The key question is: By concentrating on the object, what system am I ignoring?

Understanding the domain is the first step in solving a problem.

How to stop paying for features nobody uses? roikonen.github.io/scalablemode... #dddesign #eventstorming

Isn't it fascinating that by storing past events, we can prepare for the future? History isn’t just a record — it’s how we learn and adapt. The same applies to #EventSourcing: instead of just storing the final state, we capture every change — like a time machine for data, future-proofing systems.

Relational databases are like crime scenes where detectives must reconstruct the past, guessing how we ended up here and why things are the way they are, as traces are lost. #EventSourcing, on the other hand, records every meaningful change, like a case file, preparing you for unknown future needs.

The #ScalableModeling approach now covers new section: "Implementing Logic", bridging "sticky notes" (🟪🟩) to scalable, tech-agnostic functions. 🟩 Command Models 🟪 Command & Event Handlers 🟪 Gatekeepers Stateless functions for clear, structured business logic. roikonen.github.io/scalablemode...

To build software for complex domains sustainably and efficiently, empower delivery teams to master sub-domains, allowing team members to grow into product engineers.

When organizing teams to build scalable software, team structure should align with the architecture — not just with product needs. This ensures that essential cross-cutting concerns are treated as foundational capabilities, not afterthoughts.

Transitioning from monolith to services isn’t just about breaking things apart—it’s about rethinking how data flows and evolves. Distributed systems require event-centrism, shifting from request-driven models to data movement. Shift can be challenging but is essential for scalability and resilience.

Unlike #CQRS, in #CEQS model separation (command vs. query) isn't strictly enforced from day one. Immutable streams of private events facilitate this separation on-demand later (increased complexity, scalability, usability). Model separation isn't always needed. #ScalableModeling #EDA #EventCentric

Core domains in modern scalable operational systems should embrace business/domain events over Change Data Capture (CDC). Domain-Driven Design and Event-Driven Architecture pave the way for creating future-proof systems. #DDDesign #EventCentric #EventDriven #EDA #EventSourcing #ScalableModeling

From CRUD to Real-Time Analytics: Why Business Events Matter

Many operational systems (e.g. SaaS platforms and transactional systems) are built around CRUD operations and batch processing, but these…

medium.com

Spatial thinking with #microservices breaks when considering: ⏱️ 𝗧𝗶𝗺𝗲: Services evolve as they react. 🌊 𝗧𝘂𝗿𝗯𝘂𝗹𝗲𝗻𝗰𝗲: Networks lose messages. 𝗦𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗰𝘁 𝗶𝗻 𝘁𝗶𝗺𝗲, evolving as they work. 𝗠𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝗮𝗰𝘁 𝗶𝗻 𝘀𝗽𝗮𝗰𝗲, moving between services. Focus on message flow over service placement. #ScalableModeling

In #ScalableModeling, the Command and Query models share the same green color because, in #EventCentric thinking, they both are just different projections of same events. Their consistency models do usually differ, but even that’s not always the case.

"𝙄𝙩'𝙨 𝙙𝙚𝙫𝙚𝙡𝙤𝙥𝙚𝙧 (𝙢𝙞𝙨)𝙪𝙣𝙙𝙚𝙧𝙨𝙩𝙖𝙣𝙙𝙞𝙣𝙜 𝙩𝙝𝙖𝙩 𝙜𝙚𝙩𝙨 𝙧𝙚𝙡𝙚𝙖𝙨𝙚𝙙, 𝙣𝙤𝙩 𝙩𝙝𝙚 𝙚𝙭𝙥𝙚𝙧𝙩𝙨' 𝙠𝙣𝙤𝙬𝙡𝙚𝙙𝙜𝙚." — 𝘈𝘭𝘣𝘦𝘳𝘵𝘰 𝘉𝘳𝘢𝘯𝘥𝘰𝘭𝘪𝘯𝘪 Understanding the domain is crucial for an accurate model. Event-centrism aids domain discovery, and event immutability is key to #ScalableModeling. #DDD #EventStorming @avanscoperta.bsky.social

Scalability Challenge 3/3: Time Travel ⏱️ In #DistributedSystems, data often appears at different points in time due to inevitable consistency delays. To manage this ‘time travel’ effect and maintain system integrity, versioning and clear cause-effect flows are essential. #ScalableModeling

Scalability challenge 2/3: Tailoring Consistency ✂️ Strong consistency is the wrong default. Tailoring consistency helps optimize performance without compromising integrity. #DistributedSystems #Scalability #EventSourcing #EventCentric #ScalableModeling

Scalability challenge 1/3: Deduplication 👯‍♂️ Exactly-once delivery is unachievable in distributed systems, so we rely on effectively-once or idempotent processing to ensure duplicate messages don’t affect outcomes. #DistributedSystems #Scalability #ScalableModeling

Querying the command model in #CQRS is often debated. While it’s not designed for querying, limited reads can be useful — e.g. in clustered, in-memory models (Akka-style) for quick state access post-update. Still, querying should be rare and justified. #ScalableModeling

The 𝘁𝗵𝗿𝗲𝗲 𝗱𝗶𝗺𝗲𝗻𝘀𝗶𝗼𝗻𝘀 𝘁𝗼 𝘀𝗰𝗮𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆 via AKF Scale Cube: 1️⃣ 𝗗𝗲𝗰𝗼𝗺𝗽𝗼𝘀𝗶𝘁𝗶𝗼𝗻: Scale by splitting different things. 2️⃣ 𝗗𝘂𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻: Scale by cloning data or instances. 3️⃣ 𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻𝗶𝗻𝗴: Scale by splitting similar things into many partitions. #ScalableModeling helps you to reach all of the three dimensions.

Core components of #ScalableModeling: 💬 𝗖𝗼𝗺𝗺𝗮𝗻𝗱: Initiates actions 🟩 𝗖𝗼𝗺𝗺𝗮𝗻𝗱 𝗠𝗼𝗱𝗲𝗹: Validates commands 🟧 𝗣𝗿𝗶𝘃𝗮𝘁𝗲 𝗘𝘃𝗲𝗻𝘁: Captures internal changes 🟩 𝗤𝘂𝗲𝗿𝘆 𝗠𝗼𝗱𝗲𝗹: Optimizes data retrieval 👀 𝗤𝘂𝗲𝗿𝘆: Requests information 🟪 𝗣𝗼𝗹𝗶𝗰𝘆: Defines business rules 🟥 𝗣𝘂𝗯𝗹𝗶𝗰 𝗘𝘃𝗲𝗻𝘁: Communicates changes externally

𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗶𝘀 𝘂𝗹𝘁𝗶𝗺𝗮𝘁𝗲𝗹𝘆 𝗮 𝗺𝗼𝗱𝗲𝗹 — a conceptual solution that, while invisible, solves real-world challenges. In software engineering, the key steps are: 𝗪𝗛𝗬: Understand the purpose 𝗪𝗛𝗔𝗧: Design the conceptual model 𝗛𝗢𝗪: Implement the solution #ScalableModeling bridges WHY to HOW, with 𝗳𝗼𝗰𝘂𝘀 𝗼𝗻 𝗪𝗛𝗔𝗧.

“Doing the 𝘄𝗿𝗼𝗻𝗴 𝘁𝗵𝗶𝗻𝗴 𝗿𝗶𝗴𝗵𝘁 is not nearly as good as doing the 𝗿𝗶𝗴𝗵𝘁 𝘁𝗵𝗶𝗻𝗴 𝘄𝗿𝗼𝗻𝗴.” 𝘙𝘶𝘴𝘴𝘦𝘭𝘭 𝘓. 𝘈𝘤𝘬𝘰𝘧𝘧 We often focus more on 𝗛𝗢𝗪 (to implement) than 𝗪𝗛𝗬 and 𝗪𝗛𝗔𝗧. For long-term velocity and quality, we need to shift focus left. #ScalableModeling bridges WHY to HOW, with 𝗲𝗺𝗽𝗵𝗮𝘀𝗶𝘀 𝗼𝗻 𝗪𝗛𝗔𝗧.

After 10 years in software #Scalability & #DistributedSystems, I'm celebrating by gathering what I’ve learned into a webpage on a modeling technique for scalable systems — called #ScalableModeling 🤓. Hope it helps! roikonen.github.io/scalablemode... #CQRS #EventSourcing #DDD #EventStorming