Wiki

A living reference on software architecture, AI engineering and building products.

About this wiki

A practical reference for developers checking concepts, patterns, and tradeoffs

Why this wiki existsA short note on learning, AI, and building better software

The blog is where I work through ideas in public. This wiki is where I keep the notes I want to find again. Definitions, patterns, tradeoffs, and practical explanations for developers building real software.

Part of the motivation is to push back against the Dunning Kruger effect, that moment when a little knowledge makes a topic feel simpler than it is. The other part is helping developers who use AI understand the key concepts behind the code, so the tools make them sharper instead of more careless. AI can generate a lot, but developers still need the judgment to review designs, spot weak assumptions, and write better software.

The point of this wiki is to make those assumptions easier to inspect. Each page should help you name the concept, understand where it helps, see where it breaks, and connect it to nearby ideas.

Browse the hubs below when you need a quick refresher, or follow See also links when a topic depends on another one.

Software Architecture

Patterns, principles, and trade-offs for building maintainable systems.

All Software Architecture AI Engineering Infrastructure Product Development

Software architecture is the set of structures needed to reason about a system: components, relationships, and the principles governing their design and evolution.

This hub covers foundational patterns for decoupling teams and services, aligning code with domain language, and making trade-offs explicit before they become expensive.

A

Adapter Pattern

A structural design pattern that wraps an incompatible interface in one the client expects, letting otherwise unrelated types work together.

B

Bounded Contexts

Aligning team language with explicit code and data boundaries.

Builder Pattern

A creational design pattern that constructs complex objects step by step through a fluent builder, separating assembly from the product's representation.

C

Command Pattern

A behavioral design pattern that encapsulates a request as an object, so callers can queue, log, undo, or defer execution without knowing how the work is done.

Composite Pattern

A structural design pattern that models tree structures so clients treat individual objects and groups of objects the same way through a shared component interface.

CQRS

Separating commands that change state from queries that read it, with optional distinct write and read models.

D

Decorator Pattern

A structural design pattern that wraps an object to add behavior while keeping the same interface, so responsibilities can be composed in layers at runtime.

Domain-Driven Design

Modeling software around the business domain, bounded language, and explicit context boundaries.

E

Event Sourcing

Persisting application state as an append-only sequence of domain events instead of only the latest row values.

Event-Driven Architecture

Decoupling producers and consumers through asynchronous messaging.

Eventual Consistency

A consistency model where replicas converge to the same state over time, allowing temporary divergence after a write.

F

Facade Pattern

A structural design pattern that exposes a single, simplified interface over a complex subsystem, hiding how its parts cooperate.

Factory Method and Abstract Factory

Creational design patterns that delegate object construction to subclasses or factory families, so clients depend on abstractions instead of concrete types.

H

HATEOAS

A REST constraint where responses embed hypermedia links that tell clients which actions are available next.

HTTP Status Codes

The three-digit codes HTTP responses use to signal the outcome of a request, grouped into five classes.

I

Idempotency

Safe to run more than once without changing the outcome beyond the first successful apply.

Inbox Pattern

Deduplicating inbound messages so consumer side effects run exactly once.

O

Observer Pattern

A behavioral design pattern that lets dependents subscribe to a subject and receive automatic updates when its state changes, without tight coupling between them.

Outbox Pattern

Reliably publishing events by committing them in the same transaction as state changes.

P

Proxy Pattern

A structural design pattern that provides a surrogate with the same interface as a real object, controlling access, deferring work, or adding indirection without changing what the client sees.

R

REST

An architectural style for networked APIs built on resources, uniform HTTP semantics, and statelessness.

S

Saga Pattern

Managing distributed transactions across services with a sequence of local transactions and compensating actions.

SOLID Principles

Five object-oriented design principles for maintainable, change-tolerant code.

State Pattern

A behavioral design pattern that lets an object change its behavior when its internal state changes, by delegating to interchangeable state objects.

Strategy Pattern

A behavioral design pattern that encapsulates interchangeable algorithms behind a common interface, selected at runtime.

T

Template Method Pattern

A behavioral design pattern that defines the skeleton of an algorithm in a base class, letting subclasses override specific steps without changing the overall flow.

Two-Phase Commit

A protocol that coordinates a single atomic transaction across multiple participants using a prepare phase and a commit phase.

Explore content graph

Back to home