Shared Database Coupling Risk Prompt

This prompt is for architects and platform engineers who need to evaluate integration patterns where multiple services read from or write to the same database tables. The job-to-be-done is producing a structured risk report that identifies schema ownership conflicts, migration coordination needs, and the specific coupling type (read-only vs. read-write) for each shared table. Use this when you are auditing an existing system, reviewing a proposed architecture, or preparing for a database migration that crosses service boundaries. The ideal user has access to service-to-table mappings, schema definitions, and deployment context for the services involved.

Do not use this prompt when you need a real-time operational health check, a performance analysis of query patterns, or a security audit of data access controls. This prompt focuses on architectural coupling risk, not runtime behavior. It is also not a replacement for a full data governance review or a compliance audit. The prompt works best when you can provide concrete inputs: a list of services, the database tables they access, the type of access (read or write), and any known schema ownership assignments. Without these inputs, the model will produce generic advice that lacks the specificity needed for architectural decisions.

Before running this prompt, gather your service inventory and table access matrix. If you are evaluating a proposed design rather than an existing system, clearly mark which services and access patterns are planned versus implemented. The output should be treated as an architectural analysis artifact, not a final ruling. For high-risk systems—those handling financial transactions, healthcare data, or safety-critical operations—always have a senior architect review the findings and validate them against operational reality. The prompt identifies coupling patterns; human judgment decides which risks are acceptable and what remediation is warranted.

This prompt template is designed to produce a structured risk report when multiple services or modules share direct access to the same database tables. It forces the model to identify schema ownership conflicts, classify read-write versus read-only sharing, and surface the coordination costs of schema migrations. Use this template when you have a concrete list of services and the database objects they touch. Do not use it for abstract architecture philosophy discussions or for systems where database access is already mediated by a single API layer.

textCopy
You are an architecture reviewer specializing in integration patterns and database coupling. Your task is to analyze a set of services that share access to a common database and produce a risk report.

## INPUT

[SYSTEM_CONTEXT]

[SCHEMA_MAP]

## INSTRUCTIONS

1. For each database table or schema object listed in [SCHEMA_MAP], identify every service that accesses it.
2. Classify each access pattern as READ_ONLY, READ_WRITE, or SCHEMA_OWNER. A service is SCHEMA_OWNER if it is the designated source of truth for that table's schema migrations.
3. Flag any table that has more than one READ_WRITE service or zero SCHEMA_OWNER services as a HIGH coupling risk.
4. Flag any table where a non-owner service performs writes as a MEDIUM coupling risk.
5. For each HIGH or MEDIUM risk, describe the specific failure mode: migration conflicts, data corruption, unclear ownership, or coordination overhead.
6. Produce a coordination cost estimate (LOW, MEDIUM, HIGH) for any schema migration that touches a shared table, based on the number of consuming services.

## OUTPUT_SCHEMA

Return a valid JSON object with this structure:
{
  "analysis_date": "string",
  "tables": [
    {
      "table_name": "string",
      "accessing_services": [
        {
          "service_name": "string",
          "access_pattern": "READ_ONLY | READ_WRITE | SCHEMA_OWNER"
        }
      ],
      "risk_level": "LOW | MEDIUM | HIGH",
      "risk_description": "string or null if LOW",
      "migration_coordination_cost": "LOW | MEDIUM | HIGH",
      "remediation_suggestion": "string or null if LOW"
    }
  ],
  "summary": {
    "total_tables": "number",
    "high_risk_count": "number",
    "medium_risk_count": "number",
    "low_risk_count": "number",
    "overall_recommendation": "string"
  }
}

## CONSTRAINTS

- Only report on tables present in [SCHEMA_MAP]. Do not invent additional tables.
- If a service accesses a table through a documented API rather than direct database connection, note this but still include it with access_pattern READ_ONLY or READ_WRITE as appropriate.
- If [SCHEMA_MAP] is incomplete, note missing information in the summary rather than guessing.
- Do not recommend specific vendor tools unless they are already mentioned in [SYSTEM_CONTEXT].

## RISK_LEVEL

[RISK_LEVEL]

Adaptation notes: Replace [SYSTEM_CONTEXT] with a paragraph describing the overall system, its services, and the database technology in use. Replace [SCHEMA_MAP] with a structured list of tables and the services that access them—this can be a markdown table, a JSON array, or a bulleted list. The [RISK_LEVEL] placeholder should contain any organization-specific risk thresholds or definitions; if you have none, replace it with 'Use standard definitions as described in the instructions.' For high-stakes production databases, add a [HUMAN_REVIEW] constraint requiring that any HIGH risk finding be explicitly flagged for manual approval before the report is considered final.

The Shared Database Coupling Risk Prompt is designed to be integrated into a pre-commit or pull-request review pipeline, not as a one-off chat query. The primary input is a structured representation of your service-to-table mapping, which you must extract from your infrastructure-as-code, ORM configurations, or a live data catalog. The prompt's value comes from its ability to cross-reference this mapping against a set of architectural rules, so the harness must provide a clean, machine-readable [SERVICE_DB_MAP] and a defined [COUPLING_POLICY].

To wire this into an application, build a pre-processing step that scans your repository or infrastructure state to generate the [SERVICE_DB_MAP] JSON. This map should list each service, the database tables it accesses, and the access mode (READ or READ_WRITE). The harness should then call the LLM with the prompt template, the generated map, and your organization's [COUPLING_POLICY] (e.g., 'no two services may write to the same table'). Post-processing must validate the output against the [OUTPUT_SCHEMA]—a JSON object containing a list of violations, each with a severity, services_involved, table_name, and rationale. If the model's output fails schema validation, implement a retry loop (up to 2 attempts) that feeds the validation error back into the prompt as additional [CONSTRAINTS].

For high-stakes environments, do not treat this prompt's output as a blocking gate without human review. The harness should publish the validated risk report as a comment on the relevant pull request or architecture decision record. Log every invocation, including the full prompt, the raw model response, and the final validated output, to an observability platform. This creates an audit trail for architectural decisions. Avoid running this prompt on every commit; instead, trigger it only when files defining database access patterns (e.g., Hibernate mappings, Alembic migration files, or Terraform IAM policies for databases) are modified, preventing noise and alert fatigue.