Answers from the documentation; checking which model is on duty
Hi - I answer from the OpenSmartRoute documentation: routing, the API, plans and quotas, self-hosting. Ask away, or open a support ticket if you need a person.
Grounded in the docs - follow a source before acting on it.
This section focuses on identifying the key non-functional drivers, the most challenging areas, high-risk components, and places where requirements can be relaxed. It must justify how each part of the system should be structured at a principle/approach level and, especially, how difficult aspects will be addressed. Treat this as an architecture rationale document driven by numbers and risks from Section 3.
Before working on this section, study publicly available architecture examples of similar systems (e.g., URL shorteners, high-throughput redirect services, analytics pipelines). If external sources influence conclusions, cite them briefly in a References subsection.
Important: Use the numeric drivers and risk emojis derived in Section 3 to prioritize and evaluate options.
Introduction
Summarize the purpose of Section 4 and how it uses the numeric and risk outputs of Section 3.
State that decisions here guide subsequent detailed design and trade-offs.
Principles and Criteria
List the key non-functional priorities and principles for this system (e.g., consistency, latency, availability, data safety, cost control, evolvability).
For each principle, reference relevant numeric drivers and risks from Section 3.
Key Drivers from Section 3 (Numbers & Risks)
Extract the core drivers (e.g., Redirect RPS avg/peak, Live Links, Analytics event volume, Storage growth, Network throughput, Memory/CPU tiers).
Present them in a table with columns: Driver, Value, Tier, Risk (emoji), Notes.
Challenging Areas and High-Risk Components
Identify the most challenging aspects with rationale tied to drivers.
Provide a table: Area, Why Challenging, Primary Drivers, Risk (emoji), Potential Consequences.
Relaxed Requirements
Identify areas where requirements can be relaxed (e.g., eventual consistency for non-critical analytics, batch vs real-time, reduced retention).
Provide justification linked to business impact and drivers.
Candidate Solutions and Comparisons
For each challenging area, produce 3–5 candidate solutions.
Include a comparison table with columns: Option, Summary, Pros, Cons, Complexity, Cost, Risk (emoji), Fit to Drivers (High/Med/Low), References.
Conclude each area with a short narrative: which option(s) are recommended, what open risks remain, and whether a PoC is required (include PoC goals and acceptance checks).
Cross-Cutting Concerns
Briefly cover security, privacy, abuse prevention, observability, operability, cost management, and data lifecycle/retention.
For each, map to drivers and indicate risks and potential tactics (at approach level, not design).
Proofs of Concept (PoCs) and Validations
List proposed PoCs with objectives, metrics, and success thresholds aligned to Section 3 numbers.
Mark TODOs where feasibility or data is uncertain.
Conclusion and Next Steps
Summarize the recommended approaches and the reasoning grounded in Section 3 metrics.
Clearly list which decisions and PoCs feed into the detailed design phase.
Ensure the document uses the risk emojis and references numeric drivers from Section 3 wherever trade-offs are discussed.
Installed into a catalogue, chosen by a router
Install 04-architectural-approach and it becomes one more candidate the router can pick - when it fits.
A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.
When a provider is down or over quota the request moves on; the trace says it did.
Use it
Copy one of these into your project. Installing also returns the manifest and these snippets.
<context>
You will generate the artifact for **Section 4: Choosing the Architectural Approach** of the System Design Template.
This section focuses on identifying the key non-functional drivers, the most challenging areas, high-risk components, and places where requirements can be relaxed. It must justify how each part of the system should be structured at a principle/approach level and, especially, how difficult aspects will be addressed. Treat this as an architecture rationale document driven by numbers and risks from Section 3.
Before working on this section, study publicly available architecture examples of similar systems (e.g., URL shorteners, high-throughput redirect services, analytics pipelines). If external sources influence conclusions, cite them briefly in a References subsection.
Important: Use the numeric drivers and risk emojis derived in Section 3 to prioritize and evaluate options.
</context>
<inputs>
- file: ./requirements/project-description.md
- file: ./2-conclusions-and-assumptions/answers.md
- file: ./3-back-on-the-envelope-calculations/boe-calculations.md
</inputs>
<constraints>
- Do not produce low-level design or component wiring diagrams; stay at the **approach/principle** level.
- Use the numbers (volumes, RPS, throughput, storage) and the risk emojis from`3-back-on-the-envelope-calculations/boe-calculations.md` to drive priorities.
- For every major challenge, generate **3–5 candidate solutions** and include a **comparison table**.
- Clearly mark **assumptions** and reference the specific numeric drivers from Section 3 where used.
- Use **risk emojis** consistently: 🟩 Low, 🟨 Medium, 🟥 High. Tie risk levels to the Scaling Tiers from Section 3.
- Use **TODO** markers where data is missing or further validation is required.
- Prefer conservative (upper-bound) interpretations where uncertainty exists; call out where a **PoC** is recommended.
- Keep justifications concise and business-aligned (why it matters, consequences if ignored).
</constraints>
<recommendations>
- Structure the document so it is scannable and usable by stakeholders.
- Group by themes (e.g., Redirect path, Link storage, Analytics ingestion, Aggregation/Reporting, Security/Abuse, Cost/FinOps, Observability/SRE, Data lifecycle & retention).
- For each theme, start with the **drivers from Section 3** (numbers + risks), then outline candidate approaches and trade-offs.
- Use compact **comparison tables** for options with columns for Pros/Cons, Complexity, Cost, Risk (emoji), Fit-to-Drivers, References.
- When relevant, suggest **PoC scope** and success criteria.
- Keep explanations high-level; avoid implementation specifics.
</recommendations>
<instructions>
Using the input documents, generate a structured markdown file with the following sections:
1. **Introduction**
- Summarize the purpose of Section 4 and how it uses the numeric and risk outputs of Section 3.
- State that decisions here guide subsequent detailed design and trade-offs.
2. **Principles and Criteria**
- List the key non-functional priorities and principles for this system (e.g., consistency, latency, availability, data safety, cost control, evolvability).
- For each principle, reference relevant numeric drivers and risks from Section 3.
3. **Key Drivers from Section 3 (Numbers & Risks)**
- Extract the core drivers (e.g., Redirect RPS avg/peak, Live Links, Analytics event volume, Storage growth, Network throughput, Memory/CPU tiers).
- Present them in a table with columns: `Driver`, `Value`, `Tier`, `Risk` (emoji), `Notes`.
4. **Challenging Areas and High-Risk Components**
- Identify the most challenging aspects with rationale tied to drivers.
- Provide a table: `Area`, `Why Challenging`, `Primary Drivers`, `Risk` (emoji), `Potential Consequences`.
5. **Relaxed Requirements**
- Identify areas where requirements can be relaxed (e.g., eventual consistency for non-critical analytics, batch vs real-time, reduced retention).
- Provide justification linked to business impact and drivers.
6. **Candidate Solutions and Comparisons**
- For each challenging area, produce **3–5 candidate solutions**.
- Include a comparison table with columns: `Option`, `Summary`, `Pros`, `Cons`, `Complexity`, `Cost`, `Risk` (emoji), `Fit to Drivers` (High/Med/Low), `References`.
- Conclude each area with a short narrative: which option(s) are recommended, what open risks remain, and whether a **PoC** is required (include PoC goals and acceptance checks).
7. **Cross-Cutting Concerns**
- Briefly cover security, privacy, abuse prevention, observability, operability, cost management, and data lifecycle/retention.
- For each, map to drivers and indicate risks and potential tactics (at approach level, not design).
8. **Proofs of Concept (PoCs) and Validations**
- List proposed PoCs with objectives, metrics, and success thresholds aligned to Section 3 numbers.
- Mark TODOs where feasibility or data is uncertain.
9. **Conclusion and Next Steps**
- Summarize the recommended approaches and the reasoning grounded in Section 3 metrics.
- Clearly list which decisions and PoCs feed into the detailed design phase.
Ensure the document uses the risk emojis and references numeric drivers from Section 3 wherever trade-offs are discussed.
</instructions>
<tasks>
1. Load inputs and extract numeric drivers and risk annotations from Section 3.
2. Define principles and criteria mapped to those drivers and business goals.
3. Identify challenging areas, high-risk components, and potential relaxed requirements.
4. For each challenging area, generate 3–5 candidate solutions and a comparison table.
5. Propose PoCs for unclear/risky options with measurable goals tied to Section 3 numbers.
6. Produce the final markdown output and save it to the specified file.
</tasks>
<output>
Return **only** the final markdown contents for`./4-architectural-approach/architectural-approach.md` and create the file if it does not exist.
</output>
<validation>
- [] Uses numeric drivers and risk emojis from Section 3 throughout.
- [] Includes all required sections and tables (principles, drivers, challenging areas, relaxed requirements, comparisons, cross-cutting, PoCs, conclusion).
- [] Each challenging area has 3–5 candidate solutions with a comparison table including Risk emojis and Fit-to-Drivers.
- [] Clear PoC goals with numeric success criteria tied to Section 3.
- [] Uses TODO where information is missing or needs validation.
- [] Avoids low-level implementation details; stays at approach/principle level.
- [] References included when using publicly available examples.
</validation>
Manifest
The prompt text and its fill-in variables. Copy it or fetch it by URL from your own code.
{
"prompt": "<context>\nYou will generate the artifact for **Section 4: Choosing the Architectural Approach** of the System Design Template.\n\nThis section focuses on identifying the key non-functional drivers, the most challenging areas, high-risk components, and places where requirements can be relaxed. It must justify how each part of the system should be structured at a principle/approach level and, especially, how difficult aspects will be addressed. Treat this as an architecture rationale document driven by numbers and risks from Section 3.\n\nBefore working on this section, study publicly available architecture examples of similar systems (e.g., URL shorteners, high-throughput redirect services, analytics pipelines). If external sources influence conclusions, cite them briefly in a References subsection.\n\nImportant: Use the numeric drivers and risk emojis derived in Section 3 to prioritize and evaluate options.\n</context>\n\n<inputs>\n- file: ./requirements/project-description.md\n- file: ./2-conclusions-and-assumptions/answers.md\n- file: ./3-back-on-the-envelope-calculations/boe-calculations.md\n</inputs>\n\n<constraints>\n- Do not produce low-level design or component wiring diagrams; stay at the **approach/principle** level.\n- Use the numbers (volumes, RPS, throughput, storage) and the risk emojis from `3-back-on-the-envelope-calculations/boe-calculations.md` to drive priorities.\n- For every major challenge, generate **3–5 candidate solutions** and include a **comparison table**.\n- Clearly mark **assumptions** and reference the specific numeric drivers from Section 3 where used.\n- Use **risk emojis** consistently: 🟩 Low, 🟨 Medium, 🟥 High. Tie risk levels to the Scaling Tiers from Section 3.\n- Use **TODO** markers where data is missing or further validation is required.\n- Prefer conservative (upper-bound) interpretations where uncertainty exists; call out where a **PoC** is recommended.\n- Keep justifications concise and business-aligned (why it matters, consequences if ignored).\n</constraints>\n\n<recommendations>\n- Structure the document so it is scannable and usable by stakeholders.\n- Group by themes (e.g., Redirect path, Link storage, Analytics ingestion, Aggregation/Reporting, Security/Abuse, Cost/FinOps, Observability/SRE, Data lifecycle & retention).\n- For each theme, start with the **drivers from Section 3** (numbers + risks), then outline candidate approaches and trade-offs.\n- Use compact **comparison tables** for options with columns for Pros/Cons, Complexity, Cost, Risk (emoji), Fit-to-Drivers, References.\n- When relevant, suggest **PoC scope** and success criteria.\n- Keep explanations high-level; avoid implementation specifics.\n</recommendations>\n\n<instructions>\nUsing the input documents, generate a structured markdown file with the following sections:\n\n1. **Introduction**\n - Summarize the purpose of Section 4 and how it uses the numeric and risk outputs of Section 3.\n - State that decisions here guide subsequent detailed design and trade-offs.\n\n2. **Principles and Criteria**\n - List the key non-functional priorities and principles for this system (e.g., consistency, latency, availability, data safety, cost control, evolvability).\n - For each principle, reference relevant numeric drivers and risks from Section 3.\n\n3. **Key Drivers from Section 3 (Numbers & Risks)**\n - Extract the core drivers (e.g., Redirect RPS avg/peak, Live Links, Analytics event volume, Storage growth, Network throughput, Memory/CPU tiers).\n - Present them in a table with columns: `Driver`, `Value`, `Tier`, `Risk` (emoji), `Notes`.\n\n4. **Challenging Areas and High-Risk Components**\n - Identify the most challenging aspects with rationale tied to drivers.\n - Provide a table: `Area`, `Why Challenging`, `Primary Drivers`, `Risk` (emoji), `Potential Consequences`.\n\n5. **Relaxed Requirements**\n - Identify areas where requirements can be relaxed (e.g., eventual consistency for non-critical analytics, batch vs real-time, reduced retention).\n - Provide justification linked to business impact and drivers.\n\n6. **Candidate Solutions and Comparisons**\n - For each challenging area, produce **3–5 candidate solutions**.\n - Include a comparison table with columns: `Option`, `Summary`, `Pros`, `Cons`, `Complexity`, `Cost`, `Risk` (emoji), `Fit to Drivers` (High/Med/Low), `References`.\n - Conclude each area with a short narrative: which option(s) are recommended, what open risks remain, and whether a **PoC** is required (include PoC goals and acceptance checks).\n\n7. **Cross-Cutting Concerns**\n - Briefly cover security, privacy, abuse prevention, observability, operability, cost management, and data lifecycle/retention.\n - For each, map to drivers and indicate risks and potential tactics (at approach level, not design).\n\n8. **Proofs of Concept (PoCs) and Validations**\n - List proposed PoCs with objectives, metrics, and success thresholds aligned to Section 3 numbers.\n - Mark TODOs where feasibility or data is uncertain.\n\n9. **Conclusion and Next Steps**\n - Summarize the recommended approaches and the reasoning grounded in Section 3 metrics.\n - Clearly list which decisions and PoCs feed into the detailed design phase.\n\nEnsure the document uses the risk emojis and references numeric drivers from Section 3 wherever trade-offs are discussed.\n</instructions>\n\n<tasks>\n1. Load inputs and extract numeric drivers and risk annotations from Section 3.\n2. Define principles and criteria mapped to those drivers and business goals.\n3. Identify challenging areas, high-risk components, and potential relaxed requirements.\n4. For each challenging area, generate 3–5 candidate solutions and a comparison table.\n5. Propose PoCs for unclear/risky options with measurable goals tied to Section 3 numbers.\n6. Produce the final markdown output and save it to the specified file.\n</tasks>\n\n<output>\nReturn **only** the final markdown contents for \n`./4-architectural-approach/architectural-approach.md` and create the file if it does not exist.\n</output>\n\n<validation>\n- [] Uses numeric drivers and risk emojis from Section 3 throughout.\n- [] Includes all required sections and tables (principles, drivers, challenging areas, relaxed requirements, comparisons, cross-cutting, PoCs, conclusion).\n- [] Each challenging area has 3–5 candidate solutions with a comparison table including Risk emojis and Fit-to-Drivers.\n- [] Clear PoC goals with numeric success criteria tied to Section 3.\n- [] Uses TODO where information is missing or needs validation.\n- [] Avoids low-level implementation details; stays at approach/principle level.\n- [] References included when using publicly available examples.\n</validation>",
"variables": [],
"notes": "Generate Section 4: Choosing the Architectural Approach Mode: agent.",
"metadata": {
"source": {
"provider": "github-prompts",
"repository": "https://github.com/Constantiner/url-shortener-system-design",
"path": ".github/prompts/04-architectural-approach.prompt.md",
"ref": "ca675f16b5beca5d2ae9ebf3edeb35dfeccef86c",
"url": "https://github.com/Constantiner/url-shortener-system-design/blob/ca675f16b5beca5d2ae9ebf3edeb35dfeccef86c/.github/prompts/04-architectural-approach.prompt.md",
"key": "Constantiner/url-shortener-system-design/.github/prompts/04-architectural-approach.prompt.md"
}
}
}
Fetch it by URL: GET /api/v1/registry/constantiner-url-shortener-system-design-04-architectura-f6147a/manifest?version=1.0.0
Reviews
Star ratings from people who tried it. One review per account; edit yours any time.
No reviews yet. Install it, try it, and be the first to rate it.
