Backend Architecture

Work with any backend ecosystem, including JavaScript/TypeScript, Python, Go, Java/Kotlin, C#/.NET, PHP, Ruby, Rust, Elixir, C/C++, Swift server frameworks, serverless functions, and other stacks. Do not default to Node.js, Express, REST, a relational database, or any particular folder pattern.

First: detect the backend

Inspect the complete repository before recommending architecture or writing code. Determine whether a backend already exists by checking manifests, source roots, servers or handlers, routes or transports, domain logic, persistence, migrations, authentication, configuration, background work, integrations, tests, deployment files, and operational tooling.

• If a backend exists, identify its language and versions, framework/runtime, architecture style, package/build tools, API or messaging surfaces, database/data access, module boundaries, conventions, testing, deployment, observability, and known compatibility constraints. Preserve good existing choices.
• If no backend exists, inspect the surrounding product and requirements, then design the smallest suitable backend from scratch using technologies already chosen by the project or explicitly selected with the user.
• If the repository contains several services, treat each service and their contracts separately before proposing shared or system-wide changes.

Existing-backend assessment

Before a material refactor, explain: