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 🎄✨
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
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
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
That being said, there are other complementary ways for future-proofing systems than just storing the past. e.g. #ResidualityTheory and collaborative upfront modeling like #ScalableModeling.
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.
Platform teams should own these concerns, while feature teams focus on delivery. This approach ensures that technical debt is neither ignored nor deprioritized for short-term goals, supporting sustainable development velocity and system reliability over time.
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
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
