infrastructure-design
Skill5 starsChanged 30 days agoMITView on GitHub
Use when designing event buses or broker relays, Outbox/Inbox and CDC delivery, retries, ordering, dead-letter replay, crash recovery, concurrent workers, transaction boundaries, optimistic Aggregate concurrency, Redis caching, or database views in layered applications. Focuses on real adapter guarantees and coordination; use DDD for aggregate and context ownership.
In this repository11 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- boostSkill
- data-migration-best-practicesSkill
- ddd-best-practicesSkill
- design-patterns-best-practicesSkill
- flowSkill
- fp-best-practicesSkill
- oop-best-practicesSkill
- refactoring-best-practicesSkill
- rest-api-best-practicesSkill
- tdd-best-practicesSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 54
Read references/retry-and-concurrency.md when an operation can be retried, resumed, or executed by concurrent workers.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Infrastructure Design
Practical infrastructure patterns for layered (hexagonal/DDD) applications. The domain defines business consistency requirements, the application defines unit-of-work boundaries and capability ports, and infrastructure implements transaction and delivery mechanics.
Workflow
- Identify the concern — is this about event delivery, data consistency, read performance, or query simplification?
- Choose the right reference — load the relevant file from
references/. - Apply at the right layer — domain owns business meaning, application owns orchestration contracts, and infrastructure provides technical adapters.
- Validate the tradeoff — every infrastructure decision trades something (complexity, consistency, latency). Make the tradeoff explicit.
Quick Decision Map
| Concern | Pattern | Reference |
| Publishing domain events reliably without losing them | DB-backed Event Bus / Outbox | references/event-bus.md |
| Ensuring multiple writes succeed or fail together | Transactions in use case | references/transactions.md |
| Repeated measured reads with acceptable staleness | Cache-Aside at the narrowest reusable layer | references/cache.md |
| Complex JOIN queries repeated across the codebase | Database View / Materialized View | references/database-views.md |
| Read model needs pre-computed aggregates | Materialized view, trigger, or event-driven projection | references/database-views.md |
| Events must survive application crashes | Outbox pattern | references/event-bus.md |
| Consumers must tolerate duplicate delivery | Idempotent handler / Inbox | references/event-bus.md |
| Legacy writer cannot emit messages | Change Data Capture translator | references/event-bus.md |
| Stale Aggregate writes must not overwrite newer decisions | Optimistic version check | references/transactions.md |
Core Principles
- Core contracts first — define required ports in the domain or application core; implement adapters in infrastructure. DDD owns Repository semantics; infrastructure owns mapping, transactions, locking, caching, and Outbox mechanics.
- Transactions wrap units of work — application code or a typed decorator owns the business boundary; repositories join the scoped transaction and do not commit it independently.
- Cache is a derived copy — add it only for a measured problem, with explicit freshness, invalidation, privacy, failure, and removal policies.
- Views abstract queries, not business logic — a view is a saved SELECT, not a substitute for a domain model.
- Durability is designed, not implied — persist critical events with their writes; asynchronous delivery needs durable handoff, idempotent consumers, retries, dead-letter handling, and observability. Synchronous versus asynchronous delivery is a separate latency and coupling decision.
Related Skills
ddd-best-practices— bounded context design and aggregate boundariesdesign-patterns-best-practices— Decorator for transparent transaction/cache wrappingoop-best-practices— domain interface design and dependency inversiontdd-best-practices— real-database transaction, rollback, concurrency, and delivery testsrefactoring-best-practices— incremental migration of controller/repository transaction boundariesdata-migration-best-practices— snapshot/backfill, live-delta handoff, reconciliation, cutover, and repair workflow
References
- Read
references/retry-and-concurrency.mdwhen an operation can be retried, resumed, or executed by concurrent workers. references/event-bus.md— synchronous failure policy, transactional Outbox, relay claiming, fan-out, Inbox/idempotency, ordering, retries, dead-letter/replay, RabbitMQ and AWS EventBridge/SQS semantics, brokers, and CDCreferences/transactions.md— transaction placement, Aggregate consistency boundaries, optimistic concurrency, decorator pattern, unit of workreferences/cache.md— cache placement, keys, invalidation, failures, stampede, capacity, Redis operations, and observabilityreferences/database-views.md— views vs materialized views, trigger-maintained tables, event-driven projections, and workload-based selection
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.