Opinionated conventions for designing reliable event-driven and message-based systems.
# Event-Driven Architecture taste of a distributed systems engineer - Use events to announce facts that already happened (OrderPlaced), and commands only for requests to a single owner (ChargeCard). Confidence: 0.90 - Name events in the past tense using domain language, never after the producing table or service. Confidence: 0.85 - Define every event with a versioned schema (Avro, Protobuf or JSON Schema) in a registry and check compatibility in CI. Confidence: 0.90 - Evolve schemas only with backward-compatible changes; publish a new event type for breaking changes. Confidence: 0.85 - Assume at-least-once delivery and make every consumer idempotent with a deduplication key. Confidence: 0.95 - Publish events through the transactional outbox pattern so database writes and messages never diverge. Confidence: 0.90 - Include event id, type, version, timestamp, correlation id and causation id in every envelope. Confidence: 0.85 - Keep event payloads self-contained enough for common consumers, but do not dump whole aggregates. Confidence: 0.75 - Partition by aggregate id when ordering matters, and never rely on global ordering. Confidence: 0.85 - Route poison messages to a dead-letter queue after bounded retries with exponential backoff and jitter. Confidence: 0.90 - Alert on consumer lag and dead-letter queue depth, not just on broker health. Confidence: 0.90 - Propagate trace context through message headers so one request can be followed across services. Confidence: 0.85 - Use sagas with explicit compensating actions for multi-service workflows instead of distributed transactions. Confidence: 0.80 - Prefer choreography for simple flows and a dedicated orchestrator once a workflow has more than a few steps. Confidence: 0.70 - Reach for event sourcing only where an audit trail or temporal queries are real requirements. Confidence: 0.75 - Make replays safe: consumers must tolerate reprocessing history from any offset. Confidence: 0.80 - Set retention to match how long consumers might need to rebuild state, and document it per topic. Confidence: 0.70 - Give each topic one owning team that controls its schema and lifecycle. Confidence: 0.85 - Keep synchronous calls for queries that need an immediate answer; do not force request-response through a queue. Confidence: 0.80 - Test consumers with contract tests against the registered schema and producers with outbox integration tests. Confidence: 0.80 - Keep a living catalog (AsyncAPI or similar) of topics, producers and consumers. Confidence: 0.75
Reviews PostgreSQL and MySQL schema migrations (raw SQL or ORM-generated) for table locks, rewrites, data loss, and breaking changes, then proposes safe zero-downtime rewrites with a clear verdict.
Designs and implements AWS cloud architectures with focus on Well-Architected Framework, cost optimization, and security. Use when: 1. Designing or reviewing AWS infrastructure architecture 2. Migrating workloads to AWS or between AWS services 3. Optimizing AWS costs (right-sizing, Reserved Instances, Savings Plans) 4. Implementing AWS security, compliance, or disaster recovery 5. Troubleshooting AWS service issues or performance problems
Reviews and rewrites Git commit messages to Conventional Commits quality — clear type/scope, imperative subject, useful body explaining why — and trains the author with concrete before/after feedback.
Reviews bash and POSIX sh scripts before they run in CI, cron or production. Flags missing strict mode, rm -rf on variables that may be empty, curl piped to a shell, eval, unquoted expansions, unchecked cd, parsing ls, chmod 777, hardcoded secrets, predictable /tmp files, ssh eating a read loop, masked exit codes and bashisms under /bin/sh, then returns a fixed script. Includes a stdlib Python linter with --self-test.
