System Design
Compare architecture thinking, trade-off reasoning, and system design quality.
In this genre, the main abilities being tested are Architecture Quality, Completeness, Trade-off Reasoning.
Unlike coding, this genre puts more weight on architecture choices, scale, reliability, and trade-off handling than on runnable implementation details.
A high score here does not mean the model will write the best working code or the clearest beginner-facing explanation.
Strong models here are useful for
architecture proposals, technical trade-offs, service design, and scaling discussions.
This genre alone cannot tell you
low-level implementation quality, exact correctness, or how well the model writes for a non-technical audience.
System design: Claude Opus 5 opens on top, the GPT side brings the depth of evidence
Anthropic
OpenAI
OpenAI
Average score by model
What we weighted
Claude Opus 5 took the top of this table with its first judged appearance, and GPT-5.6 has won everything it has faced so far. Both are early records: a strong debut in architecture work says the model can reason about trade-offs at the level the judges reward, but neither has yet been stress-tested across many briefs. Read the very top as promising rather than proven.
GPT-5 mini again supplies the depth: more appearances than the models above it and a clear winning record, which keeps it the evidence-backed anchor of the genre. GPT-5.5 shows the familiar pattern of a high average with a split scorecard. Claude Sonnet 5 produced a respectable design in its first outing but lost the matchup. The Gemini family has yet to take a matchup here, and its averages sit below the pack.
Judges weigh architecture quality most, with trade-off reasoning, scalability and completeness sharing the next tier — this is a genre where naming the costs of your design matters as much as the design itself. System design prompts vary enormously in scope, so small samples swing more here than in most genres; treat the ordering as a snapshot of a fast-moving table.
Bottom line
Claude Opus 5 and GPT-5.6 look like the ones to beat on early form, while GPT-5 mini remains the pick with real evidence behind it. The Gemini models are not yet converting appearances into wins here.
This analysis is derived from Orivel's measured benchmark scores for this genre and is updated periodically. Scores are condition-dependent measurements, not absolute truth.
Top Models in This Genre
This ranking is ordered by average score within this genre only.
Latest Updated: Jul 27, 2026 09:44
Win Rate
Average Score
Win Rate
Average Score
Win Rate
Average Score
Win Rate
Average Score
Win Rate
Average Score
Win Rate
Average Score
Win Rate
Average Score
Win Rate
Average Score
| Ranked Models | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Opus 5 NEW | Anthropic |
100%
|
92
|
1 | 1 | View scores and evaluation for Claude Opus 5 |
| #2 | GPT-5.6 | OpenAI |
100%
|
90
|
2 | 2 | View scores and evaluation for GPT-5.6 |
| #3 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | View scores and evaluation for GPT-5 mini |
| #4 | GPT-5.5 | OpenAI |
50%
|
87
|
1 | 2 | View scores and evaluation for GPT-5.5 |
| #5 | Claude Sonnet 5 NEW | Anthropic |
0%
|
83
|
0 | 1 | View scores and evaluation for Claude Sonnet 5 |
| #6 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | View scores and evaluation for Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash |
0%
|
74
|
0 | 6 | View scores and evaluation for Gemini 2.5 Flash | |
| #8 | Gemini 2.5 Flash-Lite |
0%
|
68
|
0 | 5 | View scores and evaluation for Gemini 2.5 Flash-Lite |
What Is Evaluated in System Design
Scoring criteria and weight used for this genre ranking.
Architecture Quality
30.0%
This criterion is included to check Architecture Quality in the answer. It carries heavier weight because this part strongly shapes the overall result in this genre.
Completeness
20.0%
This criterion is included to check Completeness in the answer. It has meaningful weight because it affects quality in a visible way, even if it is not the only thing that matters.
Trade-off Reasoning
20.0%
This criterion is included to check Trade-off Reasoning in the answer. It has meaningful weight because it affects quality in a visible way, even if it is not the only thing that matters.
Scalability & Reliability
20.0%
This criterion is included to check Scalability & Reliability in the answer. It has meaningful weight because it affects quality in a visible way, even if it is not the only thing that matters.
Clarity
10.0%
This criterion is included to check Clarity in the answer. It is weighted more lightly because it supports the main goal rather than defining the genre by itself.
Recent tasks
System Design
Design a Real-Time Notification System for a Social Media App
You are a senior software engineer tasked with designing a real-time notification system for a rapidly growing social media application. The system needs to be scalable, reliable, and deliver notifications with low latency. Provide a detailed system design proposal.
System Design
System Design: Real-Time Notification Service
You are a senior software engineer tasked with designing a real-time notification system for a large social media platform. System Requirements: Functionality: The system must deliver notifications for various user interactions, including new followers, post likes, comments, and direct messages. Real-Time Delivery: Notifications should be delivered to online users with very low latency (under 2 seconds). Multi-Platform Support: The system must support sending notifications via mobile push (iOS/Android), web browser notifications, and email. Notification History: Users must be able to view a history of their recent notifications (e.g., the last 100). Scalability: The system must handle 100 million daily active users (DAU), with each user generating an average of 10 notification-triggering events per day. It should also handle peak loads of 5x the average traffic. Reliability: The system must be highly available (99.9% uptime) and resilient to failures. Your Task: Provide a detailed system design plan. Your plan should cover the following aspects: A high-level architectural overview. Key components and their responsibilities (e.g., API Gateway, Notification Service, Fan-out Service, etc.). Data model and choice of databases (e.g., for storing user preferences, notification history). Justify your choices. Technology stack recommendations (e.g., message queues, caching layers, push notification services). Strategies for ensuring scalability, low latency, and high availability. A discussion of potential bottlenecks and the trade-offs made in your design.
System Design
Design a URL Shortener for 10K Requests per Second
Design a URL shortening service (similar in spirit to a "tiny link" product) that can operate reliably at scale. Present your answer as a structured system design document. Functional requirements: Users submit a long URL and receive a short link (e.g., a 7-character code). Anyone visiting a short link is redirected to the original URL. Optional custom aliases requested by users must be honored if available. Basic click analytics: total click count per short link. Non-functional constraints (design to these numbers explicitly): Peak traffic: 10,000 redirect requests per second, with a read:write ratio of roughly 100:1. Redirect latency target: p99 under 50 ms measured server-side. Total stored links over 5 years: about 30 billion. Redirect availability target: 99.99% monthly. Short codes must not be guessable in bulk (avoid simple sequential exposure). Your design document should cover the following, and for each significant decision explain the trade-off you are accepting: High-level architecture and request flow for both write (create) and read (redirect) paths. Short code generation strategy, including how you guarantee uniqueness and handle custom alias collisions. Data model and choice of datastore(s), with a rough capacity/storage estimate that justifies the choice. Caching strategy and how you keep hot links fast, including cache invalidation and what happens on a cache miss. Scaling strategy: how the read path scales to meet the latency and throughput targets, and how you would partition/shard data. Reliability and failure handling: what happens when a datastore node, cache, or region fails; how you meet the availability target. How click analytics are collected without slowing down the redirect hot path. State any assumptions you make. Keep the document focused and technically concrete rather than generic.
System Design
Design a Real-Time Collaborative Whiteboard System
You are tasked with designing a high-level system architecture for a real-time collaborative whiteboard application. Core Requirements: Real-time Collaboration: Multiple users (up to 100 per session) can join a single whiteboard and see each other's actions (drawing, adding text, moving objects) in near real-time (under 200ms latency). Persistence: Whiteboard sessions must be saved so users can close the application and resume their work later. Tools: Users should have basic tools like a free-form pen, text boxes, and sticky notes. Scale and Reliability Constraints: Support up to 10,000 concurrent active whiteboard sessions. Support up to 1,000,000 total users. The service must be highly available, with 99.9% uptime. Your Task: Provide a system design that addresses the requirements above. Your response should cover: High-Level Architecture: A diagram or description of the main components (e.g., clients, load balancers, application servers, databases, real-time services) and how they interact. Real-Time Communication: Explain the technology and protocol you would use to broadcast updates to all users in a session. Data Model: Describe how you would structure the data for a whiteboard, its contents (drawings, text, etc.), and user sessions. Scalability and Reliability Strategy: How would you design the system to handle the target load and ensure high availability? Trade-offs: Discuss one major trade-off you made in your design (e.g., consistency vs. latency, choice of database, etc.).
System Design
Design a Scalable Concert Ticket Reservation System
Design a system for an online concert ticketing platform. Users can browse events, view seat availability, reserve specific seats for 10 minutes, pay through an external payment provider, and receive a digital ticket. The platform runs in one cloud region across multiple availability zones. Explicit constraints: 3 million registered users, 500,000 daily active users, major on-sale events can reach 150,000 concurrent users, peak load is 8,000 seat reservation attempts per second and 2,000 payment attempts per second, each event has up to 60,000 seats, the system must never sell the same seat twice, seat reservations expire after 10 minutes if unpaid, p95 latency for browsing and seat-map reads should be under 300 ms, p95 latency for reservation confirmation should be under 800 ms excluding payment-provider time, availability target during on-sale windows is 99.95%, recovery point objective is under 1 minute, recovery time objective is under 15 minutes, and payment provider callbacks are at-least-once, may arrive out of order, and may be delayed by up to 5 minutes. Provide a design plan. Include the main services and data stores, core APIs, data model for seats and reservations, request flow for browsing, reserving, paying, and expiring reservations, scaling strategy for traffic spikes, reliability and disaster recovery approach, consistency choices that prevent overselling, monitoring and alerting, and key trade-offs or alternatives you considered. State any reasonable assumptions you make.
System Design
Design a Scalable Notification Service
You are a senior software engineer at a rapidly growing social media company. Your task is to design a scalable and reliable notification service. This service will be responsible for sending notifications to users about various events, such as new followers, likes on their posts, comments, and direct messages.