[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GXFHG91ZCVYHX5Q7C2DAGP":3,"skill-same:01M6GXFHG91ZCVYHX5Q7C2DAGP":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6GXFHG91ZCVYHX5Q7C2DAGP","Microservices Architecture Review",null,"Deep review of microservices patterns — service boundaries, inter-service communication, data ownership, resilience patterns, and distributed system pitfalls.","malayvuong\u002Fagent-orchestra","malayvuong","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13240975?v=4","01M6GXCDVPB2VPZMDZK1KF98M0","Nguyen Minh Vuong","01M6GXCE176VDX3XV4Z4KNR33J",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fmicroservices-review\u002FSKILL.md",[],[19,5,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"architecture","microservices architecture","microservices","architecture review","review","communication","api gateway","gateway","grpc","distributed system","data","api","patterns","deep","Circuit Breaker","resilience patterns","pitfalls","resilience","circuit","2026-11-10 10:12:30",false,"---\nname: Microservices Architecture Review\ndescription: Deep review of microservices patterns — service boundaries, inter-service communication, data ownership, resilience patterns, and distributed system pitfalls.\nversion: 2026.3.1\nlicense: MIT\ntriggers:\n  lenses:\n    - logic\n    - risk\n  keywords:\n    - microservice\n    - service\n    - grpc\n    - api gateway\n    - circuit breaker\n    - saga\n---\n\nWhen reviewing microservices architecture, apply the following checks.\n\n## Service Boundaries\n\nFlag services that share a database — this is a distributed monolith, not microservices. Each service should own its data and expose it only through its API. Flag direct database queries from one service to another service's tables.\n\nFlag services that require synchronous calls to multiple other services to complete a single request — this creates a distributed call chain where any service failure cascades. Verify critical paths have at most 2-3 synchronous hops.\n\nCheck that service boundaries align with business domains (bounded contexts), not technical layers. Flag a \"user service\" that also handles authentication, notifications, and billing — these are separate domains.\n\n## Inter-Service Communication\n\nVerify synchronous calls (HTTP, gRPC) are used only when the caller needs an immediate response. Flag synchronous calls for operations that could be eventual (sending emails, updating analytics, generating reports) — use async messaging for these.\n\nCheck that service-to-service calls include timeouts, retries with exponential backoff, and circuit breakers. Flag HTTP calls without timeout configuration — the default is often infinite, causing thread exhaustion when a downstream service hangs.\n\nVerify idempotency keys are used for retry-safe operations. Flag `POST` endpoints called with retries that can create duplicate resources. Check that message consumers are idempotent — messages may be delivered more than once.\n\n## Circuit Breaker Pattern\n\nVerify circuit breakers are configured on all outbound service calls. Flag circuit breakers with thresholds that are too sensitive (1 failure triggers open) or too lenient (100 failures before open). Check that the circuit breaker has a half-open state that allows test requests through to detect recovery.\n\nVerify fallback behavior is defined for each circuit breaker — what does the service do when its dependency is unavailable? Flag services that return 500 when a non-critical dependency is down — degrade gracefully with cached data or partial responses.\n\n## Data Consistency\n\nFlag distributed transactions (two-phase commit) across services — these are fragile and slow. Verify the saga pattern is used for multi-service operations: each service performs its local transaction and publishes an event; compensating transactions handle rollback.\n\nCheck that compensating transactions are defined for every step in a saga. Flag sagas where one step has no rollback mechanism — if step 3 of 5 fails, steps 1 and 2 must be reversible.\n\nVerify eventual consistency windows are acceptable for the business case. Flag user-facing flows that require immediate consistency across services but use eventual consistency — users will see stale or conflicting data.\n\n## Service Discovery and Configuration\n\nVerify services do not hardcode the addresses of their dependencies. Flag `http:\u002F\u002Fuser-service:8080` in code — use service discovery, DNS, or environment-injected configuration. Check that configuration changes do not require redeployment.\n\nVerify health checks distinguish between \"service is alive\" (liveness) and \"service can handle requests\" (readiness). Flag health checks that return 200 when the service cannot reach its database.\n\n## API Versioning and Contracts\n\nVerify services maintain backward-compatible APIs — flag breaking changes (removed fields, changed types, new required fields) without API version bumps. Check that integration contracts are tested (consumer-driven contract tests or schema validation).\n\nFlag services that deploy together and must be released in a specific order — this indicates hidden coupling. Truly independent services can be deployed in any order.\n\n## Observability\n\nVerify distributed tracing spans the full request path across services. Flag services that do not propagate trace context to downstream calls. Check that each service emits metrics for its own health and for every dependency call.\n\nFor each finding, report: the services involved, the specific pattern violated, the production risk, and the recommended fix.\n","When reviewing microservices architecture, apply the following checks.\n\n## Service Boundaries\n\nFlag services that share a database — this is a distributed monolith, not microservices. Each service should own its data and expose it only through its API. Flag direct database queries from one service to another service's tables.\n\nFlag services that require synchronous calls to multiple other services to complete a single request — this creates a distributed call chain where any service failure cascades. Verify critical paths have at most 2-3 synchronous hops.\n\nCheck that service boundaries align with business domains (bounded contexts), not technical layers. Flag a \"user service\" that also handles authentication, notifications, and billing — these are separate domains.\n\n## Inter-Service Communication\n\nVerify synchronous calls (HTTP, gRPC) are used only when the caller needs an immediate response. Flag synchronous calls for operations that could be eventual (sending emails, updating analytics, generating reports) — use async messaging for these.\n\nCheck that service-to-service calls include timeouts, retries with exponential backoff, and circuit breakers. Flag HTTP calls without timeout configuration — the default is often infinite, causing thread exhaustion when a downstream service hangs.\n\nVerify idempotency keys are used for retry-safe operations. Flag `POST` endpoints called with retries that can create duplicate resources. Check that message consumers are idempotent — messages may be delivered more than once.\n\n## Circuit Breaker Pattern\n\nVerify circuit breakers are configured on all outbound service calls. Flag circuit breakers with thresholds that are too sensitive (1 failure triggers open) or too lenient (100 failures before open). Check that the circuit breaker has a half-open state that allows test requests through to detect recovery.\n\nVerify fallback behavior is defined for each circuit breaker — what does the service do when its dependency is unavailable? Flag services that return 500 when a non-critical dependency is down — degrade gracefully with cached data or partial responses.\n\n## Data Consistency\n\nFlag distributed transactions (two-phase commit) across services — these are fragile and slow. Verify the saga pattern is used for multi-service operations: each service performs its local transaction and publishes an event; compensating transactions handle rollback.\n\nCheck that compensating transactions are defined for every step in a saga. Flag sagas where one step has no rollback mechanism — if step 3 of 5 fails, steps 1 and 2 must be reversible.\n\nVerify eventual consistency windows are acceptable for the business case. Flag user-facing flows that require immediate consistency across services but use eventual consistency — users will see stale or conflicting data.\n\n## Service Discovery and Configuration\n\nVerify services do not hardcode the addresses of their dependencies. Flag `http:\u002F\u002Fuser-service:8080` in code — use service discovery, DNS, or environment-injected configuration. Check that configuration changes do not require redeployment.\n\nVerify health checks distinguish between \"service is alive\" (liveness) and \"service can handle requests\" (readiness). Flag health checks that return 200 when the service cannot reach its database.\n\n## API Versioning and Contracts\n\nVerify services maintain backward-compatible APIs — flag breaking changes (removed fields, changed types, new required fields) without API version bumps. Check that integration contracts are tested (consumer-driven contract tests or schema validation).\n\nFlag services that deploy together and must be released in a specific order — this indicates hidden coupling. Truly independent services can be deployed in any order.\n\n## Observability\n\nVerify distributed tracing spans the full request path across services. Flag services that do not propagate trace context to downstream calls. Check that each service emits metrics for its own health and for every dependency call.\n\nFor each finding, report: the services involved, the specific pattern violated, the production risk, and the recommended fix.\n",{"name":5,"license":15,"version":43,"triggers":44,"description":7},"2026.3.1",{"lenses":45,"keywords":48},[46,47],"logic","risk",[49,50,27,25,51,52],"microservice","service","circuit breaker","saga","main","eac6069a8690d89fd23f08d2d14e4874ed376a77",".agent-orchestra\u002Fskills\u002Fmicroservices-review",0,"https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002Fmalayvuong","www.malayvuong.com","Just a newbie at everything","2026-10-09 12:52:45",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add malayvuong\u002Fagent-orchestra --skill \"Microservices Architecture Review\"",{"tool":68,"command":69},"bunx","bunx skills add malayvuong\u002Fagent-orchestra --skill \"Microservices Architecture Review\"",{"tool":71,"command":72},"pnpm","pnpm dlx skills add malayvuong\u002Fagent-orchestra --skill \"Microservices Architecture Review\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fmicroservices-review\u002FSKILL.md",true,[],[77,115,134,152,176,196],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":99,"publishedAt":38},"01M6GXHYPRJ43SHFPFJTF87GS8","Vue.js Review","Deep review of Vue.js applications — Composition API patterns, reactivity traps, component design, Pinia state management, and performance pitfalls.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fvue-review\u002FSKILL.md",[83,88,91,94],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":92,"categoryName":93,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[23,100,101,102,103,104,105,106,107,108,109,110,30,111,112,113,32,46,35,114],"vue","js","Vue js Review","design","performance","component","state management","state","deep review","api patterns","applications","Composition","pinia","management","pinia state",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":38},"01M6GXHSPDDH1PQEN61ENMCEF5","Unity Review","Deep review of Unity C# code — object pooling, Update allocation, physics patterns, UI performance, serialization, and mobile optimization.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Funity-review\u002FSKILL.md",[],[23,122,117,104,123,124,108,125,126,127,128,31,129,32,46,130,131,132,133],"unity","update","code","ui","serialization","Optimization","mobile","physics","C#","mobile optimization","object","allocation",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":38},"01M6GXHNKTH12CGSRWDGF2H1Q9","TypeScript Review","Deep review of TypeScript code — type safety, generics patterns, strict mode compliance, type narrowing, module boundaries, and common escape hatches.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftypescript-review\u002FSKILL.md",[],[23,141,142,124,108,143,144,145,146,31,32,46,147,148,149,150,151],"typescript","typescript review","compliance","Type Safety","Safety","common","module","type","interface","consistency","mode",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":164,"publishedAt":38},"01M6GXHH3DMZD272RVH4800C67","Test Conventions","Testing patterns and conventions for code review. Covers naming, AAA structure, boundary testing, mock vs real dependencies, and coverage expectations.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftest-conventions\u002FSKILL.md",[158,161],{"categoryNo":159,"categoryName":160,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":162,"categoryName":163,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量",[165,166,154,167,168,23,124,169,170,171,31,172,173,174,175],"test","conventions","code review","testing","testing patterns","boundary","coverage","dependencies","structure","mock","naming",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":186,"publishedAt":38},"01M6GXHCAQSJDVNVRFFD1HJWTN","Terraform Review","Deep review of Terraform\u002FOpenTofu configuration — state management, module design, security hardening, drift prevention, and production safety patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fterraform-review\u002FSKILL.md",[182,185],{"categoryNo":183,"categoryName":184,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":92,"categoryName":93,"taxonomyType":86,"taxonomyTypeDesc":87},[23,187,178,103,188,106,107,108,189,190,191,192,145,193,113,194,195,32,46,147],"terraform","security","cloud","aws","hardening","Production","opentofu","iac","drift",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":38},"01M6GXH83F11CK4BQEAJPN6HDE","Swift Review","Deep review of Swift code — memory management, concurrency patterns, optionals, protocol design, SwiftUI lifecycle, and iOS platform patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fswift-review\u002FSKILL.md",[202],{"categoryNo":92,"categoryName":93,"taxonomyType":86,"taxonomyTypeDesc":87},[204,23,198,103,205,104,124,206,108,207,208,209,210,211,113,32,46,212,213,214],"swift","memory","protocol","ios","concurrency","lifecycle","swiftui","uikit","xcode","apple","platform"]