Transparent scoring methodology
How Froquiz Reviews Your System Design
The review is deterministic and scenario-specific. It evaluates the architecture you actually connected—not how polished the diagram looks and not whether you guessed one memorized solution.
What the score means
Evidence of a connected decision, not a component checklist
Every review check has a visible label and weight. Passed checks add their weight; missed checks show a scenario-specific coaching tip. Easy and medium designs receive a strong verdict from 80%, while hard scenarios require 85%. Hard scenarios also have a stricter “on track” threshold because their defining trade-offs carry more weight.
Incomplete
0–49%
Core flow or responsibilities are missing.
On track
50–79%
The system works, but important decisions remain weak.
Strong
80%+
The core path and scenario-defining decisions are present.
Hard scenarios use 70% for “on track” and 85% for “strong.” Percentages are calculated from the checks available in that scenario.
The five layers of a review
A coherent request path
The review looks for a continuous path from the client through an accepted edge layer to the application. A collection of disconnected boxes does not describe a working system.
Required architectural responsibilities
Each scenario defines responsibilities that must exist in the design: durable storage, authentication, asynchronous work, realtime delivery, media processing, coordination, search, or another domain primitive.
Explicit, correctly directed connections
A component earns credit only when it participates in the relevant flow. Direction matters: App → Queue describes publishing work; Queue → Worker describes consumption. Floating boxes do not earn points.
The decision that makes the scenario unique
A generic client–API–app–database diagram cannot score strongly everywhere. URL shortening needs a redirect hot path; ticket booking needs a seat-hold boundary; chat needs realtime delivery plus durable offline fan-out.
Capacity and trade-off choices
Where a scenario includes capacity questions or a trade-off decision, the review adds those answers to the architectural checks. The aim is to connect scale assumptions to design choices.
Concrete example
What a URL Shortener review looks for
The review accepts more than one valid storage or edge choice, but it expects those choices to form a working redirect system.
Client and edge
Traffic starts with a user and enters through a CDN, load balancer, or API gateway.
Application logic
An app server owns short-code creation and redirect resolution.
Durable mapping
The app is connected to SQL or NoSQL storage for short ↔ long URL mappings.
Redirect hot path
The app is connected to cache so popular redirects do not require a database read.
End-to-end flow
The request path is connected instead of being a set of isolated components.
Scale decision
Capacity and trade-off answers are evaluated when the scenario asks for them.
Score
72%
- ✓Durable DB stores short ↔ long mappings
- ✓Client reaches the app through an edge layer
- !Cache is missing from the redirect hot path
Connect App → Cache so popular mappings can bypass the database.
- !Capacity decision needs another look
What the review intentionally does not claim
- It does not replace a human interviewer or score spoken communication.
- It does not reward visual positioning or a prettier diagram.
- It does not require one vendor or one memorized architecture.
- It does not expose Premium solutions in the browser before access is verified.
Froquiz is a deliberate-practice tool: it catches missing flows and scenario-defining decisions consistently, then gives you a concrete starting point for another attempt.
See the review on your own architecture
The URL Shortener scenario is free. Build the request path, submit the design, inspect every passed and missed check, then improve the same design.
Build a URL Shortener free →