engineering-leadership
engineering-leadership
software-architecture
Your architecture choice is the most important decision you'll make
Architecture is the set of decisions that feel permanent after six months. An honest tour of monolith, layered, modular monolith, SOA, microservices and event-driven options: what each really costs and why the modular monolith deserves more attention than it gets.
software-architecture
How to correctly order messages in distributed systems
Message ordering in distributed systems does not come from a FIFO queue. What actually keeps events sane: idempotency as the real safety net, partition keys when order truly matters, optimistic locking as a version guard, and the traps of multiple consumers.
Latest
Cynefin framework - decide when to use Agile vs Waterfall
Cynefin framework in practice for engineers: classify a problem as clear, complicated, complex or chaotic before picking a process, so you know when Agile experiments beat Waterfall plans and what to do when production is down.
Forget about technical debt and finally start delivering
Technical debt is not the real enemy: cognitive load is. Why messy abstractions hurt because of what they do to your brain, how the database quietly kills flow, and how to stop chasing code cleanliness for its own sake and start delivering again.
Snapshot vs Event Sourcing: Why does your system lie about the past?
Snapshot databases only show the current mess, not who knocked over the chair. Event sourcing explained through an investigation lens: anatomy of an event, state recreation as time travel, why audit tables are a dead end, and the honest cost of eventual consistency.
Zanzibar authorisation system by Google
Zanzibar is how Google authorises billions of shared resources across Drive, YouTube and Calendar. A look at its relationship-based data model, the new enemy problem that forces strict consistency, and the Leopard system that keeps checks fast.
When to use Module over Class in Ruby?
Ruby modules often beat classes for service objects: why a shell class like PasswordResetInitiator is procedural code in disguise, using a module as a toolbox, mixins instead of artificial inheritance, and Data objects for tidy parameters.
Microservices - a significant cost that may not always suit your project
Microservices promise independence and deliver network calls where method calls used to be. Why small and medium teams pay the highest price: chaos scaling instead of product scaling, lost shared context, operational overhead, and the way back to sanity.
Event sourcing vs GDPR, or how to forget in a world that remembers everything
Event sourcing meets GDPR the moment a user asks to be forgotten and your log is append-only. Crypto-shredding is the elegant answer: encrypt personal data per user, delete the key, and design system boundaries so backups and read models forget too.
Your system is not unique - The power of business archetypes
Business archetypes prove your 'unique' domain is usually a store selling something unusual. Map complex requirements onto universal building blocks: product catalogue, orders, entitlements, inventory for services, party and billing, and stop reinventing the wheel.
Pseudo-modularity - why your code will fall apart anyway
Pseudo-modularity looks like clean folders and rots underneath: a change in Products breaks Inventory tests and blocks three teams. Why noun-driven modules and a shared database create facade modularity, and what real module boundaries look like.
Party Archetype - Time for architecture that doesn't hurt
Party archetype fixes the 120-column User god object: model people and companies as parties, roles as context instead of identity, and relationships as first-class entities, so a customer who becomes a B2B partner no longer needs an is_partner flag and prayer.
Microservices are not just technology - how not to build a distributed monolith?
A distributed monolith is what you get when microservice boundaries are drawn wrong. How to design autonomous modules in three phases: business analysis for boundaries, tight communication contracts, and deployment decisions driven by real architectural drivers.
An engineering approach to modularity instead of subdomain divination
Module boundaries should come from simulation, not subdomain divination. An engineering method for DDD: optimise for modifiability, simulate realistic changes against candidate boundaries, prove the split with stable contracts, and explain it to the business.
Why your event-driven architecture may actually be a distributed monolith
Event-driven architecture with Kafka can still be a distributed monolith. The anti-patterns that get you there: CRUD sourcing, property sourcing, clickbait events, missing commands, and the fixes: rich events, outbox, internal vs external events, anti-corruption layers.
Events in distributed architecture: Are you sure you know what you're sending?
Not all events are equal: domain events, Event Carried State Transfer, notification events and the Claim Check pattern each serve a different job. A typology of what you are really sending, plus the event vs command distinction that prevents architectural chaos.
When you should NOT use messaging, or how not to make things harder for yourself
Messaging is not a default answer. When a business flow is synchronous, queues add complexity without value and message ordering becomes your biggest pitfall. How to recognise the cases where a simple synchronous call keeps the system easier to build and debug.
From strategy to code: How the discovery process changes thinking about DDD
DDD is not aggregates first: the discovery process is the heart of it. Why strategy with domain experts beats jumping into tactical patterns, the language pitfalls that derail modelling, the 'what if' trap, and why change must come from above and below.
The difference between Kafka and RabbitMQ: Choosing the right messaging system
Kafka and RabbitMQ solve messaging differently: Kafka is an append-only streaming log with fan-out consumers and offsets, RabbitMQ a classic broker with exchange routing and explicit acks. A side by side comparison to pick the right one for your system.
What is IDesign way in architecture?
The IDesign method by Juval Lowy structures software architecture for change instead of functional decomposition. Why decomposing by requirements breaks systems over time, the core IDesign principles, a three-step design process, and implementation tips.
Understanding the C4 model for software architecture
The C4 model documents software architecture as four zoom levels: Context, Containers, Components, and Code. See how the diagrams work on a concrete example (a paid blog application) and why this hierarchy keeps developers and stakeholders oriented.