Architecture health check: see what to fix first

Describe the system you run today and answer 8 quick questions. You get a score on 7 indicators, the concerns that stand out, and the improvements to look at first.

Free, with results on screen. No email needed. It's a rule-based read of your answers, not an audit, and the report says so.

8 questions and a short description · Results on screen

Architecture health check

What it does, how it's deployed, and anything you already suspect. If you have them, name them with these words: rate limit, JWT or OAuth, secret or KMS, index, replica or failover, version, schema, TTL. The check looks for those words.

Common answers are preselected. Change any that don't match.

Where it runs
Main database
Cache
Queue
API style
How you deploy
Traffic
What you can see in production (pick all that apply)

About this check

What the 7 indicators mean

  • Scalability

    Can you add capacity by adding machines? A single VM or slow work inside the request path lowers it.

  • Reliability

    How quickly you can deploy, roll back and notice a failure. Automated deploys and alerting raise it.

  • Security

    The controls at the edge: rate limits, authentication and how secrets are stored. Payment keys or personal data in scope raise the stakes.

  • Observability

    Whether you can see what the system is doing: logs, metrics, traces and alerts.

  • Database

    Whether the data layer fits how it's used: indexes, replicas, and one clear source of truth.

  • Caching

    Whether frequent reads avoid the database, and whether cached data is cleared when it changes.

  • API architecture

    Versioning, request validation, and one consistent style for callers.

  • How the score works

    Each indicator starts from a baseline and moves with your answers. A single VM lowers scalability; a CI/CD pipeline and alerting raise reliability. Words in your description count too: "rate limit", "index" or "replica" tells the check that control exists.

    Scores stay between 5 and 95, because a form can't prove a system is perfect or hopeless. The overall figure is the average of the seven.

  • What it can't tell you

    It doesn't see your code, your data or your traffic, and it runs no tests. Treat the result as a list of questions worth asking. A review of the real system, or a load test against production-shaped data, answers them.

  • When to talk to an engineer

    If a concern mentions key custody or personal data, if two or more indicators need attention, or before a launch or a technical due-diligence review. Bring the result to the call, so we start from what you already know.