python-service-architecture

Python Service Architecture

Use this for new product/server architecture work in Python. For new backend products, decide the service boundary from ownership, data source of truth, runtime isolation, scaling, release cadence, and rollback needs before choosing microservice, modular monolith, worker, script, or package shape. This skill distills proven Python backend, AI-service hosting, worker, package, and data-access patterns, but must not assume any existing repository, product domain, package path, service identifier, database, or legacy service layout.

Skill Routing

• Use this skill for Python architecture decisions, microservice decomposition, service decomposition, API contract shape, storage ownership, async execution, worker/job design, observability, reliability, release readiness, and platform boundaries.
• Use python-service-dev when the user asks to implement, modify, scaffold, generate Python code, or apply a diagnosis/test strategy in Python code. A localized refactor (某文件/某类) also belongs to python-service-dev; only service-wide layering/boundary redesign stays here, and a multi-stage refactor delivery must re-enter product-rd-workflow. For root-cause debugging use defect-diagnosis first; for test-layer choice use testing-strategy first.
• Use product-rd-workflow first when the request spans product shaping, architecture, implementation, review, release, and learning loops.
• Use defect-diagnosis first when the task is to reproduce, isolate, instrument, fix, verify, or root-cause a backend defect, regression, repeated failure, review finding, or failing test.
• Use testing-strategy when the main question is which unit, integration, contract, or E2E layer should prove behavior; then return here for Python architecture impact.
• Use llm-inference-integration for inference, RAG, prompt, model-routing, evaluation, replay, token-cost, and batch-inference design. This skill only owns the Python service boundary that hosts or calls those capabilities.
• Use go-microservice-architecture for Go services. Do not load Go skill rules for Python work unless the task is explicitly cross-language contract design.
• Use platform-observability for logs/metrics/traces/log-id propagation/dashboards/alerts/SLI-SLO design. This skill owns only the service-side observability surface (what fields the handler emits, what middleware the framework attaches, what health endpoints exist); the cross-cutting evidence stack belongs there.
• Use platform-service-connectivity for service mesh, service discovery, mTLS, multi-environment lane routing, retry/timeout/circuit-breaker policy, and framework client/server middleware for cross-service hops. This skill defines what the service exposes (health endpoints, ctx propagation, error-code conformance); routing/policy lives there.
• Use platform-release-engineering for environment/lane matrix, canary/blue-green, promotion gates, rollback playbook, secret distribution, dynamic-config (config-center) vs static-config split, image build pipeline. This skill owns the service-side contracts (what the service consumes from the secret store and config center); release flow lives there.
• Use codebase-specific skills only when the task is explicitly about an existing repository.
• When changing an architecture rule that implementation must obey, name the downstream execution owner before landing: python-service-dev for code mechanics, testing-strategy for proof layer, platform skills for runtime contracts, and product-rd-workflow for cross-stage gates. If the rule also applies outside Python, route through skill-extraction-workflow and mirror or explicitly skip sibling architecture/dev skills.
• For money, billing, quota, permission, tenant/user data isolation, privacy, high-impact AI, repeated writes, async finality, or incident-explanation risk, start from product-rd-workflow and its high-risk resilience gate before choosing Python service boundaries or fallback behavior.