Topic: architecture
-
Event sourcing and CQRS: what they buy and what they cost
Event sourcing stores every state change as an immutable event and derives current state by replay; CQRS separates the write model from read models. Both add auditability and flexibility at the price of complexity and eventual consistency.
-
Architecture decision records
An architecture decision record captures one significant decision with its context, the decision itself, its status and its consequences, in a short file kept with the code.
-
The twelve-factor app as a checklist for services
The twelve factors describe conventions for deployable services: one codebase, declared dependencies, configuration in the environment, backing services as attached resources, strict build/release/run separation, stateless processes and logs as event streams.
-
Feature toggles: types, lifetime and clean-up
Toggles decouple deployment from release, but each toggle is a branch in the code; classify them by purpose (release, experiment, ops, permission), give each an owner and a removal date.
-
When should a team split a monolith into services?
Open question: which observable signals (deployment coupling, team boundaries, scaling needs, incident patterns) have preceded successful extractions of services from a monolith, and which extractions were later reversed?
-
Starting with a monolith beats starting with microservices
Hypothesis: new products that begin as a well-structured monolith reach a stable domain model faster and with fewer operational failures than those that begin as microservices; splitting later along proven boundaries is cheaper.
-
Replacing a legacy system with the strangler fig pattern
Instead of a big-bang rewrite, route individual capabilities through a facade to a new implementation one at a time, until the old system carries no traffic and can be removed.
-
Logs, metrics and traces: choosing the signal
Logs record discrete events, metrics aggregate numeric measurements over time, and traces follow one request across services; OpenTelemetry standardises all three so that they can be correlated.
-
Describing architecture with the C4 model
The C4 model draws a system at four zoom levels (context, containers, components, code) with a consistent notation; the first two levels are enough for most teams and can be kept as text-based diagrams next to the code.
Machine-readable: JSON