sqlite
sqlite
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
Risk management - The illusions of intuition in software engineering
Risk management for engineers, without the vibes: use expected value to judge a rewrite, spot base rate neglect and sunk cost in tech choices, apply Bayesian thinking during outages, and price technical debt with a four-step calculation you can run today.
Structured logging in Rails 8.1 with Rails.event
Structured logging lands in Rails 8.1 with the Rails.event API. How the Structured Event Reporter replaces regex-parsed log lines with JSON events, plus tags, context, schemas, debug mode, and how to subscribe and test events in your own app.
Ruby 4.0 - a big update for its 30th birthday
Ruby 4.0 marks the language's 30th birthday with maturity instead of revolution: saner syntax for multiline conditions, faster boot with fewer requires, a maturing Ractor story, hidden performance gems, and protection against command injection.
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.
How to tame race conditions in read models
Race conditions in read models are the price of parallel event-driven systems. How to handle events arriving out of order: treat the read model as an anti-corruption layer, separate facts from rumours, and build projections that survive an effect arriving before its cause.
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.
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.
The challenge of measuring developer productivity- the SPACE framework
Measuring developer productivity with one metric backfires: lines of code and commit counts create misleading incentives. The SPACE framework tracks five dimensions (satisfaction, performance, activity, collaboration, efficiency) for an honest picture of a team.
The necessity of architectural advancement
Evolutionary architecture treats change as a design input, not a threat. Why rigid paradigms fail, how to make well-informed architecture decisions, and how identifying architectural drivers and writing fitness functions keeps your system resilient.
Living documentation with the P3 model: A practical guide for engineers
Living documentation stops going stale with the P3 model: define the Purpose (why you document), the Process (how it stays current), and the Product (what readers get). A practical framework for engineers tired of outdated wikis and misleading docs.
Who is the product owner?
A product owner is defined by real decision-making power: controlling the budget, setting the vision and strategy, and owning the backlog. What each responsibility means in practice, plus a blunt list of cases where, despite the title, you are not the product owner.
Sample DDD explanation in Ruby with Event-sourcing and Event-driven development
Domain Driven Design in Ruby with a working example: aggregates, entities, value objects, and repositories built around a ProductCatalog, then extended with event-driven design and event sourcing, where projections rebuild state from events instead of a database.