[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-microsoft-system-type-event-driven":3,"mdc--4adfyr-key":33,"related-repo-microsoft-system-type-event-driven":629,"related-org-microsoft-system-type-event-driven":712},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":22,"repoUrl":23,"updatedAt":24,"license":25,"forks":26,"topics":27,"repo":28,"sourceUrl":31,"mdContent":32},"system-type-event-driven","design event-driven and message-based systems","Domain patterns for event-driven and message-based systems — pub\u002Fsub, event sourcing, CQRS, sagas, delivery guarantees, schema evolution, and failure modes. Use when designing or evaluating systems built around events, messages, or asynchronous workflows.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"microsoft","Microsoft","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fmicrosoft.png",[12,16,19],{"name":13,"slug":14,"type":15},"Architecture","architecture","tag",{"name":17,"slug":18,"type":15},"System Design","system-design",{"name":20,"slug":21,"type":15},"Messaging","messaging",0,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design","2026-07-07T06:53:27.291427",null,1,[],{"repoUrl":23,"stars":22,"forks":26,"topics":29,"description":30},[],"Systems-design capabilities for Amplifier sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Ftree\u002FHEAD\u002Fskills\u002Fsystem-type-event-driven","---\nname: system-type-event-driven\ndescription: \"Domain patterns for event-driven and message-based systems — pub\u002Fsub, event sourcing, CQRS, sagas, delivery guarantees, schema evolution, and failure modes. Use when designing or evaluating systems built around events, messages, or asynchronous workflows.\"\n---\n\n# System Type: Event-Driven\n\nPatterns, guarantees, and failure modes for event-driven and message-based architectures.\n\n---\n\n## Core Patterns\n\n### Publish\u002FSubscribe\n**What it is.** Producers publish events to a topic; consumers subscribe and receive independently. Decouples producers from consumers.\n**When to use.** Fan-out notifications, audit logging, updating multiple read models, cross-domain integration where the producer shouldn't know about consumers.\n**When to avoid.** When you need a synchronous response. When ordering across topics matters. When the number of consumers is always exactly one (point-to-point is simpler).\n\n### Event Sourcing\n**What it is.** Store state as a sequence of immutable events rather than current-state snapshots. Current state is derived by replaying events.\n**When to use.** Audit requirements (financial, regulatory). When you need to reconstruct historical state. When different consumers need different projections of the same data.\n**When to avoid.** CRUD-heavy domains with simple state. When event schema evolution is harder than the audit benefit. When the team has no experience with eventual consistency patterns. When query patterns require complex joins across aggregates.\n\n### CQRS (Command Query Responsibility Segregation)\n**What it is.** Separate the write model (commands) from the read model (queries). Each is optimized for its access pattern.\n**When to use.** When read and write patterns are drastically different (many reads, few writes, or vice versa). When you need different data shapes for different consumers. Pairs naturally with event sourcing.\n**When to avoid.** Simple domains where read and write models are essentially the same. When the consistency lag between write and read models is unacceptable. When the operational complexity of maintaining two models exceeds the benefit.\n\n### Saga Pattern\n**What it is.** Coordinate a multi-step business process across services using a sequence of local transactions with compensating actions for rollback.\n**When to use.** Business processes that span multiple services and need all-or-nothing semantics without distributed transactions.\n**When to avoid.** When a single database transaction suffices. When the compensating actions are harder to implement correctly than the forward actions.\n\n### Choreography vs. Orchestration\n**Choreography:** Each service listens for events and decides independently what to do next. No central coordinator. Good for simple flows with few steps. Becomes opaque when flows are complex — the process is implicit in the event chain.\n**Orchestration:** A central coordinator explicitly directs each step. Easier to understand, monitor, and modify complex flows. The orchestrator is a single point of failure and a coupling point.\n**The real question:** How many steps? Fewer than 4: choreography is simpler. More than 4: orchestration is easier to reason about and debug.\n\n## Delivery Guarantees\n\n**At-most-once.** Fire and forget. Message may be lost. Use for: metrics, non-critical notifications, telemetry where gaps are acceptable.\n\n**At-least-once.** Messages are retried until acknowledged. Messages may be delivered more than once. Use for: anything where losing a message is worse than processing it twice. **Requires idempotent consumers.**\n\n**Exactly-once.** Each message processed exactly once. In distributed systems, this is achieved through at-least-once delivery + idempotent processing (not through the broker alone). Use for: financial transactions, inventory updates, anything where duplicates cause real harm.\n\n**The practical reality:** Most systems use at-least-once delivery with idempotent consumers. Exactly-once semantics from the broker (e.g., Kafka transactions) have significant performance and complexity costs.\n\n## Idempotency in Consumers\n\nEvery consumer in an at-least-once system must handle duplicate messages safely.\n\n**Strategies:**\n- **Idempotency key.** Store processed message IDs. Skip duplicates. Watch for: unbounded storage of processed IDs — add TTL-based cleanup.\n- **Natural idempotency.** Design operations to be inherently idempotent. \"Set balance to $100\" is idempotent; \"add $10 to balance\" is not.\n- **Optimistic concurrency.** Use version numbers or ETags. Reject stale updates. Works well with event sourcing.\n- **Deduplication window.** Accept that duplicates outside the window may be processed twice. Appropriate when the cost of occasional duplicates is low.\n\n## Schema Evolution\n\nEvents are contracts. They must evolve without breaking consumers.\n\n**Backward compatible changes (safe):**\n- Adding optional fields with defaults\n- Adding new event types (existing consumers ignore them)\n\n**Breaking changes (dangerous):**\n- Removing fields\n- Renaming fields\n- Changing field types\n- Changing the semantics of existing fields\n\n**Strategies:**\n- **Schema registry.** Validate compatibility at publish time. Prevents breaking changes from reaching consumers.\n- **Versioned events.** `OrderPlaced.v1`, `OrderPlaced.v2`. Consumers subscribe to the version they understand. Producer may need to emit both during migration.\n- **Consumer-driven contracts.** Consumers declare what fields they need. Breaking changes are detected before deployment.\n- **Upcasting.** Transform old events to new schema at read time. Keeps the event store immutable while evolving the consumer's view.\n\n## Dead Letter Queues\n\nMessages that repeatedly fail processing go to a dead letter queue (DLQ) rather than blocking the main queue or being silently dropped.\n\n**When to use.** Always in production systems. The alternative is losing messages or blocking processing.\n\n**What to include.** Original message, error details, retry count, timestamp, source topic. Enough context to diagnose and replay.\n\n**Operational requirements.** Monitoring on DLQ depth. Alerting when messages arrive. A replay mechanism to reprocess after fixing the consumer bug. Regular review — a growing DLQ is a symptom, not a solution.\n\n## Common Failure Modes\n\n- **Poison messages.** A single malformed message crashes the consumer repeatedly. Mitigation: retry limits + DLQ. Never retry infinitely.\n- **Consumer lag.** Consumers fall behind producers. Mitigation: monitoring lag metrics, autoscaling consumers, partitioning for parallelism.\n- **Ordering violations.** Messages arrive out of order. Mitigation: partition by entity ID (same entity, same partition), sequence numbers, reordering buffers.\n- **Duplicate processing.** At-least-once delivery causes side effects to happen twice. Mitigation: idempotent consumers (see above).\n- **Backpressure collapse.** Producers overwhelm consumers and the message broker. Mitigation: producer rate limiting, consumer scaling, broker capacity planning.\n- **Split brain.** Competing consumers process the same message differently due to state inconsistency. Mitigation: single-partition-per-consumer assignment, leader election.\n\n## Anti-Patterns\n\n- **Event soup.** Publishing events for everything without a clear schema or purpose. Leads to undiscoverable, unmaintainable event flows.\n- **Using events for synchronous queries.** Publishing an event and immediately polling for the result. Use request\u002Fresponse if you need a synchronous answer.\n- **Fat events.** Putting entire entity state in every event. Events should carry what changed, not everything. Consumers that need full state should maintain their own projection.\n- **Ignoring ordering.** Assuming messages arrive in order when the broker doesn't guarantee it for your partitioning scheme.\n- **No dead letter strategy.** Silently dropping or infinitely retrying failed messages. Both are data loss — one is obvious, the other is subtle.\n- **Shared event bus as integration layer.** Using one event bus for all services with no ownership model. Becomes a shared mutable dependency worse than a shared database.\n",{"data":34,"body":35},{"name":4,"description":6},{"type":36,"children":37},"root",[38,46,52,56,63,70,95,101,122,128,149,155,176,182,206,212,222,237,247,257,263,268,276,321,327,332,340,353,361,384,391,451,457,462,471,481,491,497,560,566],{"type":39,"tag":40,"props":41,"children":42},"element","h1",{"id":4},[43],{"type":44,"value":45},"text","System Type: Event-Driven",{"type":39,"tag":47,"props":48,"children":49},"p",{},[50],{"type":44,"value":51},"Patterns, guarantees, and failure modes for event-driven and message-based architectures.",{"type":39,"tag":53,"props":54,"children":55},"hr",{},[],{"type":39,"tag":57,"props":58,"children":60},"h2",{"id":59},"core-patterns",[61],{"type":44,"value":62},"Core Patterns",{"type":39,"tag":64,"props":65,"children":67},"h3",{"id":66},"publishsubscribe",[68],{"type":44,"value":69},"Publish\u002FSubscribe",{"type":39,"tag":47,"props":71,"children":72},{},[73,79,81,86,88,93],{"type":39,"tag":74,"props":75,"children":76},"strong",{},[77],{"type":44,"value":78},"What it is.",{"type":44,"value":80}," Producers publish events to a topic; consumers subscribe and receive independently. Decouples producers from consumers.\n",{"type":39,"tag":74,"props":82,"children":83},{},[84],{"type":44,"value":85},"When to use.",{"type":44,"value":87}," Fan-out notifications, audit logging, updating multiple read models, cross-domain integration where the producer shouldn't know about consumers.\n",{"type":39,"tag":74,"props":89,"children":90},{},[91],{"type":44,"value":92},"When to avoid.",{"type":44,"value":94}," When you need a synchronous response. When ordering across topics matters. When the number of consumers is always exactly one (point-to-point is simpler).",{"type":39,"tag":64,"props":96,"children":98},{"id":97},"event-sourcing",[99],{"type":44,"value":100},"Event Sourcing",{"type":39,"tag":47,"props":102,"children":103},{},[104,108,110,114,116,120],{"type":39,"tag":74,"props":105,"children":106},{},[107],{"type":44,"value":78},{"type":44,"value":109}," Store state as a sequence of immutable events rather than current-state snapshots. Current state is derived by replaying events.\n",{"type":39,"tag":74,"props":111,"children":112},{},[113],{"type":44,"value":85},{"type":44,"value":115}," Audit requirements (financial, regulatory). When you need to reconstruct historical state. When different consumers need different projections of the same data.\n",{"type":39,"tag":74,"props":117,"children":118},{},[119],{"type":44,"value":92},{"type":44,"value":121}," CRUD-heavy domains with simple state. When event schema evolution is harder than the audit benefit. When the team has no experience with eventual consistency patterns. When query patterns require complex joins across aggregates.",{"type":39,"tag":64,"props":123,"children":125},{"id":124},"cqrs-command-query-responsibility-segregation",[126],{"type":44,"value":127},"CQRS (Command Query Responsibility Segregation)",{"type":39,"tag":47,"props":129,"children":130},{},[131,135,137,141,143,147],{"type":39,"tag":74,"props":132,"children":133},{},[134],{"type":44,"value":78},{"type":44,"value":136}," Separate the write model (commands) from the read model (queries). Each is optimized for its access pattern.\n",{"type":39,"tag":74,"props":138,"children":139},{},[140],{"type":44,"value":85},{"type":44,"value":142}," When read and write patterns are drastically different (many reads, few writes, or vice versa). When you need different data shapes for different consumers. Pairs naturally with event sourcing.\n",{"type":39,"tag":74,"props":144,"children":145},{},[146],{"type":44,"value":92},{"type":44,"value":148}," Simple domains where read and write models are essentially the same. When the consistency lag between write and read models is unacceptable. When the operational complexity of maintaining two models exceeds the benefit.",{"type":39,"tag":64,"props":150,"children":152},{"id":151},"saga-pattern",[153],{"type":44,"value":154},"Saga Pattern",{"type":39,"tag":47,"props":156,"children":157},{},[158,162,164,168,170,174],{"type":39,"tag":74,"props":159,"children":160},{},[161],{"type":44,"value":78},{"type":44,"value":163}," Coordinate a multi-step business process across services using a sequence of local transactions with compensating actions for rollback.\n",{"type":39,"tag":74,"props":165,"children":166},{},[167],{"type":44,"value":85},{"type":44,"value":169}," Business processes that span multiple services and need all-or-nothing semantics without distributed transactions.\n",{"type":39,"tag":74,"props":171,"children":172},{},[173],{"type":44,"value":92},{"type":44,"value":175}," When a single database transaction suffices. When the compensating actions are harder to implement correctly than the forward actions.",{"type":39,"tag":64,"props":177,"children":179},{"id":178},"choreography-vs-orchestration",[180],{"type":44,"value":181},"Choreography vs. Orchestration",{"type":39,"tag":47,"props":183,"children":184},{},[185,190,192,197,199,204],{"type":39,"tag":74,"props":186,"children":187},{},[188],{"type":44,"value":189},"Choreography:",{"type":44,"value":191}," Each service listens for events and decides independently what to do next. No central coordinator. Good for simple flows with few steps. Becomes opaque when flows are complex — the process is implicit in the event chain.\n",{"type":39,"tag":74,"props":193,"children":194},{},[195],{"type":44,"value":196},"Orchestration:",{"type":44,"value":198}," A central coordinator explicitly directs each step. Easier to understand, monitor, and modify complex flows. The orchestrator is a single point of failure and a coupling point.\n",{"type":39,"tag":74,"props":200,"children":201},{},[202],{"type":44,"value":203},"The real question:",{"type":44,"value":205}," How many steps? Fewer than 4: choreography is simpler. More than 4: orchestration is easier to reason about and debug.",{"type":39,"tag":57,"props":207,"children":209},{"id":208},"delivery-guarantees",[210],{"type":44,"value":211},"Delivery Guarantees",{"type":39,"tag":47,"props":213,"children":214},{},[215,220],{"type":39,"tag":74,"props":216,"children":217},{},[218],{"type":44,"value":219},"At-most-once.",{"type":44,"value":221}," Fire and forget. Message may be lost. Use for: metrics, non-critical notifications, telemetry where gaps are acceptable.",{"type":39,"tag":47,"props":223,"children":224},{},[225,230,232],{"type":39,"tag":74,"props":226,"children":227},{},[228],{"type":44,"value":229},"At-least-once.",{"type":44,"value":231}," Messages are retried until acknowledged. Messages may be delivered more than once. Use for: anything where losing a message is worse than processing it twice. ",{"type":39,"tag":74,"props":233,"children":234},{},[235],{"type":44,"value":236},"Requires idempotent consumers.",{"type":39,"tag":47,"props":238,"children":239},{},[240,245],{"type":39,"tag":74,"props":241,"children":242},{},[243],{"type":44,"value":244},"Exactly-once.",{"type":44,"value":246}," Each message processed exactly once. In distributed systems, this is achieved through at-least-once delivery + idempotent processing (not through the broker alone). Use for: financial transactions, inventory updates, anything where duplicates cause real harm.",{"type":39,"tag":47,"props":248,"children":249},{},[250,255],{"type":39,"tag":74,"props":251,"children":252},{},[253],{"type":44,"value":254},"The practical reality:",{"type":44,"value":256}," Most systems use at-least-once delivery with idempotent consumers. Exactly-once semantics from the broker (e.g., Kafka transactions) have significant performance and complexity costs.",{"type":39,"tag":57,"props":258,"children":260},{"id":259},"idempotency-in-consumers",[261],{"type":44,"value":262},"Idempotency in Consumers",{"type":39,"tag":47,"props":264,"children":265},{},[266],{"type":44,"value":267},"Every consumer in an at-least-once system must handle duplicate messages safely.",{"type":39,"tag":47,"props":269,"children":270},{},[271],{"type":39,"tag":74,"props":272,"children":273},{},[274],{"type":44,"value":275},"Strategies:",{"type":39,"tag":277,"props":278,"children":279},"ul",{},[280,291,301,311],{"type":39,"tag":281,"props":282,"children":283},"li",{},[284,289],{"type":39,"tag":74,"props":285,"children":286},{},[287],{"type":44,"value":288},"Idempotency key.",{"type":44,"value":290}," Store processed message IDs. Skip duplicates. Watch for: unbounded storage of processed IDs — add TTL-based cleanup.",{"type":39,"tag":281,"props":292,"children":293},{},[294,299],{"type":39,"tag":74,"props":295,"children":296},{},[297],{"type":44,"value":298},"Natural idempotency.",{"type":44,"value":300}," Design operations to be inherently idempotent. \"Set balance to $100\" is idempotent; \"add $10 to balance\" is not.",{"type":39,"tag":281,"props":302,"children":303},{},[304,309],{"type":39,"tag":74,"props":305,"children":306},{},[307],{"type":44,"value":308},"Optimistic concurrency.",{"type":44,"value":310}," Use version numbers or ETags. Reject stale updates. Works well with event sourcing.",{"type":39,"tag":281,"props":312,"children":313},{},[314,319],{"type":39,"tag":74,"props":315,"children":316},{},[317],{"type":44,"value":318},"Deduplication window.",{"type":44,"value":320}," Accept that duplicates outside the window may be processed twice. Appropriate when the cost of occasional duplicates is low.",{"type":39,"tag":57,"props":322,"children":324},{"id":323},"schema-evolution",[325],{"type":44,"value":326},"Schema Evolution",{"type":39,"tag":47,"props":328,"children":329},{},[330],{"type":44,"value":331},"Events are contracts. They must evolve without breaking consumers.",{"type":39,"tag":47,"props":333,"children":334},{},[335],{"type":39,"tag":74,"props":336,"children":337},{},[338],{"type":44,"value":339},"Backward compatible changes (safe):",{"type":39,"tag":277,"props":341,"children":342},{},[343,348],{"type":39,"tag":281,"props":344,"children":345},{},[346],{"type":44,"value":347},"Adding optional fields with defaults",{"type":39,"tag":281,"props":349,"children":350},{},[351],{"type":44,"value":352},"Adding new event types (existing consumers ignore them)",{"type":39,"tag":47,"props":354,"children":355},{},[356],{"type":39,"tag":74,"props":357,"children":358},{},[359],{"type":44,"value":360},"Breaking changes (dangerous):",{"type":39,"tag":277,"props":362,"children":363},{},[364,369,374,379],{"type":39,"tag":281,"props":365,"children":366},{},[367],{"type":44,"value":368},"Removing fields",{"type":39,"tag":281,"props":370,"children":371},{},[372],{"type":44,"value":373},"Renaming fields",{"type":39,"tag":281,"props":375,"children":376},{},[377],{"type":44,"value":378},"Changing field types",{"type":39,"tag":281,"props":380,"children":381},{},[382],{"type":44,"value":383},"Changing the semantics of existing fields",{"type":39,"tag":47,"props":385,"children":386},{},[387],{"type":39,"tag":74,"props":388,"children":389},{},[390],{"type":44,"value":275},{"type":39,"tag":277,"props":392,"children":393},{},[394,404,431,441],{"type":39,"tag":281,"props":395,"children":396},{},[397,402],{"type":39,"tag":74,"props":398,"children":399},{},[400],{"type":44,"value":401},"Schema registry.",{"type":44,"value":403}," Validate compatibility at publish time. Prevents breaking changes from reaching consumers.",{"type":39,"tag":281,"props":405,"children":406},{},[407,412,414,421,423,429],{"type":39,"tag":74,"props":408,"children":409},{},[410],{"type":44,"value":411},"Versioned events.",{"type":44,"value":413}," ",{"type":39,"tag":415,"props":416,"children":418},"code",{"className":417},[],[419],{"type":44,"value":420},"OrderPlaced.v1",{"type":44,"value":422},", ",{"type":39,"tag":415,"props":424,"children":426},{"className":425},[],[427],{"type":44,"value":428},"OrderPlaced.v2",{"type":44,"value":430},". Consumers subscribe to the version they understand. Producer may need to emit both during migration.",{"type":39,"tag":281,"props":432,"children":433},{},[434,439],{"type":39,"tag":74,"props":435,"children":436},{},[437],{"type":44,"value":438},"Consumer-driven contracts.",{"type":44,"value":440}," Consumers declare what fields they need. Breaking changes are detected before deployment.",{"type":39,"tag":281,"props":442,"children":443},{},[444,449],{"type":39,"tag":74,"props":445,"children":446},{},[447],{"type":44,"value":448},"Upcasting.",{"type":44,"value":450}," Transform old events to new schema at read time. Keeps the event store immutable while evolving the consumer's view.",{"type":39,"tag":57,"props":452,"children":454},{"id":453},"dead-letter-queues",[455],{"type":44,"value":456},"Dead Letter Queues",{"type":39,"tag":47,"props":458,"children":459},{},[460],{"type":44,"value":461},"Messages that repeatedly fail processing go to a dead letter queue (DLQ) rather than blocking the main queue or being silently dropped.",{"type":39,"tag":47,"props":463,"children":464},{},[465,469],{"type":39,"tag":74,"props":466,"children":467},{},[468],{"type":44,"value":85},{"type":44,"value":470}," Always in production systems. The alternative is losing messages or blocking processing.",{"type":39,"tag":47,"props":472,"children":473},{},[474,479],{"type":39,"tag":74,"props":475,"children":476},{},[477],{"type":44,"value":478},"What to include.",{"type":44,"value":480}," Original message, error details, retry count, timestamp, source topic. Enough context to diagnose and replay.",{"type":39,"tag":47,"props":482,"children":483},{},[484,489],{"type":39,"tag":74,"props":485,"children":486},{},[487],{"type":44,"value":488},"Operational requirements.",{"type":44,"value":490}," Monitoring on DLQ depth. Alerting when messages arrive. A replay mechanism to reprocess after fixing the consumer bug. Regular review — a growing DLQ is a symptom, not a solution.",{"type":39,"tag":57,"props":492,"children":494},{"id":493},"common-failure-modes",[495],{"type":44,"value":496},"Common Failure Modes",{"type":39,"tag":277,"props":498,"children":499},{},[500,510,520,530,540,550],{"type":39,"tag":281,"props":501,"children":502},{},[503,508],{"type":39,"tag":74,"props":504,"children":505},{},[506],{"type":44,"value":507},"Poison messages.",{"type":44,"value":509}," A single malformed message crashes the consumer repeatedly. Mitigation: retry limits + DLQ. Never retry infinitely.",{"type":39,"tag":281,"props":511,"children":512},{},[513,518],{"type":39,"tag":74,"props":514,"children":515},{},[516],{"type":44,"value":517},"Consumer lag.",{"type":44,"value":519}," Consumers fall behind producers. Mitigation: monitoring lag metrics, autoscaling consumers, partitioning for parallelism.",{"type":39,"tag":281,"props":521,"children":522},{},[523,528],{"type":39,"tag":74,"props":524,"children":525},{},[526],{"type":44,"value":527},"Ordering violations.",{"type":44,"value":529}," Messages arrive out of order. Mitigation: partition by entity ID (same entity, same partition), sequence numbers, reordering buffers.",{"type":39,"tag":281,"props":531,"children":532},{},[533,538],{"type":39,"tag":74,"props":534,"children":535},{},[536],{"type":44,"value":537},"Duplicate processing.",{"type":44,"value":539}," At-least-once delivery causes side effects to happen twice. Mitigation: idempotent consumers (see above).",{"type":39,"tag":281,"props":541,"children":542},{},[543,548],{"type":39,"tag":74,"props":544,"children":545},{},[546],{"type":44,"value":547},"Backpressure collapse.",{"type":44,"value":549}," Producers overwhelm consumers and the message broker. Mitigation: producer rate limiting, consumer scaling, broker capacity planning.",{"type":39,"tag":281,"props":551,"children":552},{},[553,558],{"type":39,"tag":74,"props":554,"children":555},{},[556],{"type":44,"value":557},"Split brain.",{"type":44,"value":559}," Competing consumers process the same message differently due to state inconsistency. Mitigation: single-partition-per-consumer assignment, leader election.",{"type":39,"tag":57,"props":561,"children":563},{"id":562},"anti-patterns",[564],{"type":44,"value":565},"Anti-Patterns",{"type":39,"tag":277,"props":567,"children":568},{},[569,579,589,599,609,619],{"type":39,"tag":281,"props":570,"children":571},{},[572,577],{"type":39,"tag":74,"props":573,"children":574},{},[575],{"type":44,"value":576},"Event soup.",{"type":44,"value":578}," Publishing events for everything without a clear schema or purpose. Leads to undiscoverable, unmaintainable event flows.",{"type":39,"tag":281,"props":580,"children":581},{},[582,587],{"type":39,"tag":74,"props":583,"children":584},{},[585],{"type":44,"value":586},"Using events for synchronous queries.",{"type":44,"value":588}," Publishing an event and immediately polling for the result. Use request\u002Fresponse if you need a synchronous answer.",{"type":39,"tag":281,"props":590,"children":591},{},[592,597],{"type":39,"tag":74,"props":593,"children":594},{},[595],{"type":44,"value":596},"Fat events.",{"type":44,"value":598}," Putting entire entity state in every event. Events should carry what changed, not everything. Consumers that need full state should maintain their own projection.",{"type":39,"tag":281,"props":600,"children":601},{},[602,607],{"type":39,"tag":74,"props":603,"children":604},{},[605],{"type":44,"value":606},"Ignoring ordering.",{"type":44,"value":608}," Assuming messages arrive in order when the broker doesn't guarantee it for your partitioning scheme.",{"type":39,"tag":281,"props":610,"children":611},{},[612,617],{"type":39,"tag":74,"props":613,"children":614},{},[615],{"type":44,"value":616},"No dead letter strategy.",{"type":44,"value":618}," Silently dropping or infinitely retrying failed messages. Both are data loss — one is obvious, the other is subtle.",{"type":39,"tag":281,"props":620,"children":621},{},[622,627],{"type":39,"tag":74,"props":623,"children":624},{},[625],{"type":44,"value":626},"Shared event bus as integration layer.",{"type":44,"value":628}," Using one event bus for all services with no ownership model. Becomes a shared mutable dependency worse than a shared database.",{"items":630,"total":711},[631,643,658,668,674,689,701],{"slug":632,"name":632,"fn":633,"description":634,"org":635,"tags":636,"stars":22,"repoUrl":23,"updatedAt":642},"design-philosophy-domain-driven","model complex systems with domain-driven design","Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[637,638,641],{"name":13,"slug":14,"type":15},{"name":639,"slug":640,"type":15},"Data Modeling","data-modeling",{"name":17,"slug":18,"type":15},"2026-07-07T06:53:28.678913",{"slug":644,"name":644,"fn":645,"description":646,"org":647,"tags":648,"stars":22,"repoUrl":23,"updatedAt":657},"design-philosophy-linux","apply Unix and Linux design philosophy","The Unix\u002FLinux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[649,650,653,656],{"name":13,"slug":14,"type":15},{"name":651,"slug":652,"type":15},"Engineering","engineering",{"name":654,"slug":655,"type":15},"Linux","linux",{"name":17,"slug":18,"type":15},"2026-05-13T06:14:50.770309",{"slug":659,"name":659,"fn":660,"description":661,"org":662,"tags":663,"stars":22,"repoUrl":23,"updatedAt":667},"system-type-distributed","apply distributed systems design patterns","Foundational patterns for distributed systems — consensus, consistency models, replication, partitioning, clock synchronization, distributed transactions, and failure modes. Use when designing or evaluating any system that spans multiple nodes, processes, or failure domains.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[664,665,666],{"name":13,"slug":14,"type":15},{"name":651,"slug":652,"type":15},{"name":17,"slug":18,"type":15},"2026-05-13T06:14:49.388552",{"slug":4,"name":4,"fn":5,"description":6,"org":669,"tags":670,"stars":22,"repoUrl":23,"updatedAt":24},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[671,672,673],{"name":13,"slug":14,"type":15},{"name":20,"slug":21,"type":15},{"name":17,"slug":18,"type":15},{"slug":675,"name":675,"fn":676,"description":677,"org":678,"tags":679,"stars":22,"repoUrl":23,"updatedAt":688},"system-type-ml-serving","design ML serving and training systems","Domain patterns for ML\u002FAI serving and training systems — model serving, feature stores, training pipelines, experiment tracking, A\u002FB testing, GPU scheduling, and failure modes. Use when designing or evaluating machine learning infrastructure, model serving platforms, or AI-powered product features.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[680,683,686,687],{"name":681,"slug":682,"type":15},"AI Infrastructure","ai-infrastructure",{"name":684,"slug":685,"type":15},"Deep Learning","deep-learning",{"name":651,"slug":652,"type":15},{"name":17,"slug":18,"type":15},"2026-07-03T16:31:59.997224",{"slug":690,"name":690,"fn":691,"description":692,"org":693,"tags":694,"stars":22,"repoUrl":23,"updatedAt":700},"system-type-real-time","design real-time and collaborative systems","Domain patterns for real-time and collaborative systems — persistent connections, state synchronization, conflict resolution, presence, fan-out, and failure modes. Use when designing or evaluating chat systems, collaborative editors, live dashboards, gaming backends, or any system with bidirectional real-time communication.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[695,696,699],{"name":13,"slug":14,"type":15},{"name":697,"slug":698,"type":15},"Real-time","real-time",{"name":17,"slug":18,"type":15},"2026-07-07T06:53:26.004577",{"slug":702,"name":702,"fn":703,"description":704,"org":705,"tags":706,"stars":22,"repoUrl":23,"updatedAt":710},"systems-design-review-methodology","perform systems design reviews","Use when the \u002Fsystems-design-review mode is active. 7-step design review methodology -- understand the design, classify the system, evaluate against codebase, adversarial analysis, tradeoff validation, synthesis, and action items. Governs conversation flow, delegation patterns, and user validation checkpoints.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[707,708,709],{"name":13,"slug":14,"type":15},{"name":651,"slug":652,"type":15},{"name":17,"slug":18,"type":15},"2026-07-03T16:31:58.725837",7,{"items":713,"total":904},[714,734,755,776,789,806,817,830,845,860,879,892],{"slug":715,"name":715,"fn":716,"description":717,"org":718,"tags":719,"stars":731,"repoUrl":732,"updatedAt":733},"rushstack-best-practices","manage Rush monorepos with best practices","Provides best practices and guidance for working with Rush monorepos. Use when the user is working in a Rush-based repository, asks about Rush commands (install, update, build, rebuild), needs help with project selection, dependency management, build caching, subspace configuration, or troubleshooting Rush-specific issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[720,721,724,725,728],{"name":651,"slug":652,"type":15},{"name":722,"slug":723,"type":15},"Local Development","local-development",{"name":9,"slug":8,"type":15},{"name":726,"slug":727,"type":15},"Project Management","project-management",{"name":729,"slug":730,"type":15},"Rush","rush",6484,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frushstack","2026-04-06T18:34:44.965032",{"slug":735,"name":735,"fn":736,"description":737,"org":738,"tags":739,"stars":752,"repoUrl":753,"updatedAt":754},"azure-ai-agents-persistent-dotnet","build AI agents with Azure .NET SDK","Azure AI Agents Persistent SDK for .NET. Low-level SDK for creating and managing AI agents with threads, messages, runs, and tools. Use for agent CRUD, conversation threads, streaming responses, function calling, file search, and code interpreter. Triggers: \"PersistentAgentsClient\", \"persistent agents\", \"agent threads\", \"agent runs\", \"streaming agents\", \"function calling agents .NET\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[740,743,746,749],{"name":741,"slug":742,"type":15},".NET","net",{"name":744,"slug":745,"type":15},"Agents","agents",{"name":747,"slug":748,"type":15},"Azure","azure",{"name":750,"slug":751,"type":15},"LLM","llm",2804,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills","2026-07-03T16:32:10.297433",{"slug":756,"name":756,"fn":757,"description":758,"org":759,"tags":760,"stars":752,"repoUrl":753,"updatedAt":775},"azure-ai-anomalydetector-java","build anomaly detection applications with Java","Build anomaly detection applications with Azure AI Anomaly Detector SDK for Java. Use when implementing univariate\u002Fmultivariate anomaly detection, time-series analysis, or AI-powered monitoring.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[761,764,765,768,771,772],{"name":762,"slug":763,"type":15},"Analytics","analytics",{"name":747,"slug":748,"type":15},{"name":766,"slug":767,"type":15},"Data Analysis","data-analysis",{"name":769,"slug":770,"type":15},"Java","java",{"name":9,"slug":8,"type":15},{"name":773,"slug":774,"type":15},"Monitoring","monitoring","2026-05-13T06:14:16.261754",{"slug":777,"name":777,"fn":778,"description":779,"org":780,"tags":781,"stars":752,"repoUrl":753,"updatedAt":788},"azure-ai-contentsafety-java","build content moderation applications with Azure AI","Build content moderation applications with Azure AI Content Safety SDK for Java. Use when implementing text\u002Fimage analysis, blocklist management, or harm detection for hate, violence, sexual content, and self-harm.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[782,783,784,785],{"name":681,"slug":682,"type":15},{"name":747,"slug":748,"type":15},{"name":769,"slug":770,"type":15},{"name":786,"slug":787,"type":15},"Security","security","2026-07-07T06:53:31.293235",{"slug":790,"name":790,"fn":791,"description":792,"org":793,"tags":794,"stars":752,"repoUrl":753,"updatedAt":805},"azure-ai-contentsafety-py","detect harmful content with Azure AI Content Safety","Azure AI Content Safety SDK for Python. Use for detecting harmful content in text and images with multi-severity classification.\nTriggers: \"azure-ai-contentsafety\", \"ContentSafetyClient\", \"content moderation\", \"harmful content\", \"text analysis\", \"image analysis\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[795,796,799,800,801,804],{"name":747,"slug":748,"type":15},{"name":797,"slug":798,"type":15},"Compliance","compliance",{"name":750,"slug":751,"type":15},{"name":9,"slug":8,"type":15},{"name":802,"slug":803,"type":15},"Python","python",{"name":786,"slug":787,"type":15},"2026-07-18T05:14:23.017504",{"slug":807,"name":807,"fn":808,"description":809,"org":810,"tags":811,"stars":752,"repoUrl":753,"updatedAt":816},"azure-ai-language-conversations-py","implement conversational language understanding with Python","Implement Conversational Language Understanding (CLU) using the azure-ai-language-conversations Python SDK. Use when working with ConversationAnalysisClient to analyze conversation intent and entities, building NLP features, or integrating language understanding into applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[812,813,814,815],{"name":762,"slug":763,"type":15},{"name":747,"slug":748,"type":15},{"name":750,"slug":751,"type":15},{"name":802,"slug":803,"type":15},"2026-07-31T05:54:29.068751",{"slug":818,"name":818,"fn":819,"description":820,"org":821,"tags":822,"stars":752,"repoUrl":753,"updatedAt":829},"azure-ai-translation-text-py","translate text using Azure AI services","Azure AI Text Translation SDK for real-time text translation, transliteration, language detection, and dictionary lookup. Use for translating text content in applications.\nTriggers: \"text translation\", \"translator\", \"translate text\", \"transliterate\", \"TextTranslationClient\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[823,826,827,828],{"name":824,"slug":825,"type":15},"API Development","api-development",{"name":747,"slug":748,"type":15},{"name":9,"slug":8,"type":15},{"name":802,"slug":803,"type":15},"2026-07-18T05:14:16.988376",{"slug":831,"name":831,"fn":832,"description":833,"org":834,"tags":835,"stars":752,"repoUrl":753,"updatedAt":844},"azure-ai-vision-imageanalysis-py","analyze images with Azure AI Vision","Azure AI Vision Image Analysis SDK for captions, tags, objects, OCR, people detection, and smart cropping. Use for computer vision and image understanding tasks.\nTriggers: \"image analysis\", \"computer vision\", \"OCR\", \"object detection\", \"ImageAnalysisClient\", \"image caption\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[836,837,840,843],{"name":747,"slug":748,"type":15},{"name":838,"slug":839,"type":15},"Computer Vision","computer-vision",{"name":841,"slug":842,"type":15},"Images","images",{"name":802,"slug":803,"type":15},"2026-07-18T05:14:18.007737",{"slug":846,"name":846,"fn":847,"description":848,"org":849,"tags":850,"stars":752,"repoUrl":753,"updatedAt":859},"azure-appconfiguration-java","manage configuration with Azure App Configuration","Azure App Configuration SDK for Java. Centralized application configuration management with key-value settings, feature flags, and snapshots.\nTriggers: \"ConfigurationClient java\", \"app configuration java\", \"feature flag java\", \"configuration setting java\", \"azure config java\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[851,852,855,858],{"name":747,"slug":748,"type":15},{"name":853,"slug":854,"type":15},"Configuration","configuration",{"name":856,"slug":857,"type":15},"Feature Flags","feature-flags",{"name":769,"slug":770,"type":15},"2026-07-03T16:32:01.278468",{"slug":861,"name":861,"fn":862,"description":863,"org":864,"tags":865,"stars":752,"repoUrl":753,"updatedAt":878},"azure-cosmos-rust","build applications with Azure Cosmos DB","Azure Cosmos DB library for Rust (NoSQL API). Document CRUD, containers, and globally distributed data.\nTriggers: \"cosmos db rust\", \"CosmosClient rust\", \"document crud rust\", \"NoSQL rust\", \"partition key rust\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[866,869,872,875],{"name":867,"slug":868,"type":15},"Cosmos DB","cosmos-db",{"name":870,"slug":871,"type":15},"Database","database",{"name":873,"slug":874,"type":15},"NoSQL","nosql",{"name":876,"slug":877,"type":15},"Rust","rust","2026-07-31T05:54:27.021432",{"slug":880,"name":880,"fn":862,"description":881,"org":882,"tags":883,"stars":752,"repoUrl":753,"updatedAt":891},"azure-cosmos-ts","Azure Cosmos DB JavaScript\u002FTypeScript SDK (@azure\u002Fcosmos) for data plane operations. Use for CRUD operations on documents, queries, bulk operations, and container management. Triggers: \"Cosmos DB\", \"@azure\u002Fcosmos\", \"CosmosClient\", \"document CRUD\", \"NoSQL queries\", \"bulk operations\", \"partition key\", \"container.items\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[884,885,886,887,888],{"name":867,"slug":868,"type":15},{"name":870,"slug":871,"type":15},{"name":9,"slug":8,"type":15},{"name":873,"slug":874,"type":15},{"name":889,"slug":890,"type":15},"TypeScript","typescript","2026-07-03T16:31:19.368382",{"slug":893,"name":893,"fn":894,"description":895,"org":896,"tags":897,"stars":752,"repoUrl":753,"updatedAt":903},"azure-data-tables-java","build table storage applications with Java","Build table storage applications with Azure Tables SDK for Java. Use when working with Azure Table Storage or Cosmos DB Table API for NoSQL key-value data, schemaless storage, or structured data at scale.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[898,899,900,901,902],{"name":747,"slug":748,"type":15},{"name":867,"slug":868,"type":15},{"name":870,"slug":871,"type":15},{"name":769,"slug":770,"type":15},{"name":873,"slug":874,"type":15},"2026-05-13T06:14:17.582229",267]