<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>howitworks.dev</title><description>Tech, systems, and engineering — from a software architect’s perspective.</description><link>https://howitworks.dev/</link><item><title>Agentic systems: what OpenAI and Anthropic actually tell you to build</title><link>https://howitworks.dev/agentic-systems/</link><guid isPermaLink="true">https://howitworks.dev/agentic-systems/</guid><description>Workflows before agents, three foundations before orchestration, guardrails before autonomy — a synthesis of the two canonical guides on building LLM systems that do things, not just answer questions.</description></item><item><title>API security: most of it is not authentication</title><link>https://howitworks.dev/api-security/</link><guid isPermaLink="true">https://howitworks.dev/api-security/</guid><description>Input validation vs sanitization, parameterized queries, BOLA and mass assignment, rate limiting, SSRF, CORS, CSRF, and the rest of the surface that remains after identity and authorization are solved.</description></item><item><title>REST, GraphQL, gRPC: who pays the cost of change</title><link>https://howitworks.dev/api-styles/</link><guid isPermaLink="true">https://howitworks.dev/api-styles/</guid><description>The three dominant API styles and what each one actually buys you — coupling, evolvability, performance, tooling — plus the event stream as the fourth style nobody quite calls an API.</description></item><item><title>Authn and authz: identity is infrastructure, authorization is domain</title><link>https://howitworks.dev/authn-authz/</link><guid isPermaLink="true">https://howitworks.dev/authn-authz/</guid><description>Sessions vs tokens, OAuth2 and OIDC properly distinguished, RBAC vs ABAC vs ReBAC, and where authorization actually belongs in a microservice estate.</description></item><item><title>Caching: a denormalization pretending to be an optimization</title><link>https://howitworks.dev/caching/</link><guid isPermaLink="true">https://howitworks.dev/caching/</guid><description>Where to cache, what invalidation actually costs, the stampede and hot-key problems, and why &quot;cache aside&quot; is the default but not always the answer.</description></item><item><title>CI/CD: the pipeline is the release process, not a decoration on it</title><link>https://howitworks.dev/ci-cd/</link><guid isPermaLink="true">https://howitworks.dev/ci-cd/</guid><description>What continuous integration and continuous delivery actually mean, how GitHub Actions / GitLab CI / Jenkins compare, and the deployment strategies — blue/green, canary, rolling — that turn a passing pipeline into a safe rollout.</description></item><item><title>Consistency models: pick the weakest one you can defend</title><link>https://howitworks.dev/consistency-models/</link><guid isPermaLink="true">https://howitworks.dev/consistency-models/</guid><description>CAP is the meme; the real content is linearizable vs serializable vs snapshot vs causal vs eventual — and which apps actually need which.</description></item><item><title>Containers and Kubernetes: the unit of deployment is a process, not a machine</title><link>https://howitworks.dev/containers-kubernetes/</link><guid isPermaLink="true">https://howitworks.dev/containers-kubernetes/</guid><description>What a container actually is, why the image format matters more than the runtime, and what Kubernetes is really solving — scheduling, networking, rollouts — once you strip away the YAML.</description></item><item><title>Conway&apos;s Law and Team Topologies: the org chart is the architecture</title><link>https://howitworks.dev/conway-team-topologies/</link><guid isPermaLink="true">https://howitworks.dev/conway-team-topologies/</guid><description>Why the shape of the software mirrors the shape of the organization — and how Skelton and Pais&apos;s four team types and three interaction modes turn that observation into a design tool.</description></item><item><title>Database selection: the default is Postgres, and the deviations need reasons</title><link>https://howitworks.dev/database-selection/</link><guid isPermaLink="true">https://howitworks.dev/database-selection/</guid><description>Relational, document, key-value, graph, time-series, columnar, search — what each store is actually for, and when the right answer is &quot;just use Postgres&quot; and when it is not.</description></item><item><title>Domain-Driven Design: modeling the business, not the database</title><link>https://howitworks.dev/domain-driven-design/</link><guid isPermaLink="true">https://howitworks.dev/domain-driven-design/</guid><description>A tour of DDD as Evans defined it and Vernon, Young, and Brandolini carried forward — ubiquitous language, bounded contexts, aggregates, events, CQRS, and Event Storming.</description></item><item><title>Event-driven architecture: the log is the contract</title><link>https://howitworks.dev/event-driven-architecture/</link><guid isPermaLink="true">https://howitworks.dev/event-driven-architecture/</guid><description>Events, commands, and the three flavors of event-driven systems — notification, state transfer, and sourcing — plus the outbox, CDC, and the eventual-consistency bill that comes with them.</description></item><item><title>Design Patterns: the Gang of Four, thirty years on</title><link>https://howitworks.dev/gang-of-four-design-patterns/</link><guid isPermaLink="true">https://howitworks.dev/gang-of-four-design-patterns/</guid><description>A tour of the most important Gamma, Helm, Johnson, and Vlissides patterns — Strategy, Observer, Decorator, Adapter, Composite, Factory Method, Command, State, and the rest — and which ones still earn their keep.</description></item><item><title>Hexagonal, Clean, Onion: dependencies point inward</title><link>https://howitworks.dev/hexagonal-clean-onion/</link><guid isPermaLink="true">https://howitworks.dev/hexagonal-clean-onion/</guid><description>Three names for the same architecture — ports, adapters, and the single rule they all enforce: the domain does not know about the world around it.</description></item><item><title>Incident management: the humans are part of the system</title><link>https://howitworks.dev/incident-management/</link><guid isPermaLink="true">https://howitworks.dev/incident-management/</guid><description>On-call, severity levels, the incident commander role, blameless postmortems — and why the discipline is really about reducing time-to-detect, time-to-mitigate, and time-to-recur.</description></item><item><title>Infrastructure as code: the state file is the source of truth, not the repo</title><link>https://howitworks.dev/infrastructure-as-code/</link><guid isPermaLink="true">https://howitworks.dev/infrastructure-as-code/</guid><description>Terraform, CloudFormation, Pulumi, and CDK compared on what they actually do — plus the state file, drift, modules, and why the declarative model breaks at the edges.</description></item><item><title>Kafka: a distributed log, and what you can build on top of one</title><link>https://howitworks.dev/kafka/</link><guid isPermaLink="true">https://howitworks.dev/kafka/</guid><description>How Kafka actually works — topics, partitions, offsets, replication — and how those primitives turn into microservice communication, event streaming, CDC, and log aggregation.</description></item><item><title>Microservices: a pattern language, not a silver bullet</title><link>https://howitworks.dev/microservices/</link><guid isPermaLink="true">https://howitworks.dev/microservices/</guid><description>A tour of the microservice architecture as a set of forces and patterns — decomposition, data, sagas, the distributed monolith — in the spirit of microservices.io.</description></item><item><title>Migration patterns: how to change a running system without stopping it</title><link>https://howitworks.dev/migration-patterns/</link><guid isPermaLink="true">https://howitworks.dev/migration-patterns/</guid><description>Strangler fig, parallel run, dual writes, expand-contract, feature flags, and backfill — the patterns that turn big-bang rewrites into sequences of small, reversible steps.</description></item><item><title>Observability: the three pillars are not the whole building</title><link>https://howitworks.dev/observability/</link><guid isPermaLink="true">https://howitworks.dev/observability/</guid><description>Logs, metrics, traces, SLIs, SLOs, error budgets, and the cardinality bill — what observability actually is, and why buying a tool is not the same as adopting the discipline.</description></item><item><title>Platform engineering: the platform is a product</title><link>https://howitworks.dev/platform-engineering/</link><guid isPermaLink="true">https://howitworks.dev/platform-engineering/</guid><description>Platform teams, golden paths, thinnest viable platform, self-service as the discipline — and why &quot;build an internal Heroku&quot; fails differently depending on what you mean by it.</description></item><item><title>React best practices and anti-patterns: composition over cleverness</title><link>https://howitworks.dev/react-best-practices/</link><guid isPermaLink="true">https://howitworks.dev/react-best-practices/</guid><description>State colocation, lifting and deriving, the useEffect trap, memoization mythology, and the controlled/uncontrolled split — plus the anti-patterns that show up in every large React codebase eventually.</description></item><item><title>Resilience patterns: treat the network as hostile</title><link>https://howitworks.dev/resilience-patterns/</link><guid isPermaLink="true">https://howitworks.dev/resilience-patterns/</guid><description>Idempotency, timeouts, retries, circuit breakers, bulkheads — what each pattern actually buys you, and how they compose into a system that degrades instead of collapsing.</description></item><item><title>Schema and API evolution: every stable system has a deprecation culture</title><link>https://howitworks.dev/schema-api-evolution/</link><guid isPermaLink="true">https://howitworks.dev/schema-api-evolution/</guid><description>Expand-contract, additive change, versioning, deprecation windows — how to change a running system without breaking the things already using it.</description></item><item><title>Testing strategies: pyramids, trophies, and honeycombs</title><link>https://howitworks.dev/testing-strategies/</link><guid isPermaLink="true">https://howitworks.dev/testing-strategies/</guid><description>What each test-shape is optimizing for, where contract tests fit, the fakes-vs-mocks question, and why the right mix is shaped like the system.</description></item></channel></rss>