Software Architecture on dplabs — Software Engineering & Technology Consultancy

Monolith vs Microservices: Starting With the Right Question

Mon, 06 Jan 2025 00:00:00 +0000

The monolith vs microservices debate has produced more heat than light over the past decade. Both sides have oversimplified. “Monoliths don’t scale” is demonstrably false — StackOverflow ran a monolith for years serving massive traffic. “Microservices are only for large teams” ignores the many small teams that have shipped them successfully.

The real question is not which architecture is better in the abstract. It’s which architecture fits your current constraints: your team size, your organizational structure, your operational maturity, and your actual scaling requirements.

Event-Driven Architecture: When Events Help and When They Hurt

Mon, 23 Dec 2024 00:00:00 +0000

Event-driven architecture has become fashionable, which means it’s being applied in situations where it doesn’t fit. Events are a powerful architectural tool for specific problems. They’re a significant operational burden when applied indiscriminately.

Understanding when events help and when they hurt requires understanding what problems they actually solve.

Events vs Commands

The distinction matters more than most tutorials acknowledge.

A command expresses intent: “place this order,” “cancel this payment,” “reserve this inventory item.” It’s addressed to a specific recipient and implies that recipient is responsible for handling it. Commands can be rejected. They have an expected response.

Architecture Decision Records: Making Technical Decisions Explicit

Mon, 11 Nov 2024 00:00:00 +0000

Every significant technical decision your team makes will be questioned later. When the original authors have left. When the context has changed. When someone proposes replacing the system. When a new engineer asks “why does this work like this?”

Most teams have no good answer to these questions. The reasons behind decisions live in people’s heads, in Slack threads that are impossible to find, or nowhere at all.

Architecture Decision Records are a lightweight practice that fixes this. They capture not just what was decided, but why — including what was considered and rejected. The investment is small. The return compounds over time.

Distributed Systems: The Problems You Get for Free

Mon, 28 Oct 2024 00:00:00 +0000

Every system that communicates over a network is a distributed system, and distributed systems fail in ways that single-process applications don’t. This is not opinion — it’s physics. Networks drop packets. Clocks drift. Services restart. Disks fail. These things happen regardless of how carefully you write your application code.

The teams that get distributed systems right don’t eliminate these failures. They design so that their systems remain correct despite them.

The Modular Monolith: An Architecture Pattern That Deserves More Attention

Mon, 14 Oct 2024 00:00:00 +0000

The software industry has a microservices fixation. Over the last decade, “monolith” became almost a pejorative, and teams moved to distributed architectures before they had the scale, team size, or operational maturity to justify them.

The result has been widespread over-engineering: systems that are harder to understand, harder to debug, harder to change, and more expensive to operate — not because distributed systems are inherently bad, but because the problems they solve weren’t actually present.