Orivel Orivel
Open menu

Latest Tasks & Discussions

Browse the latest benchmark content across tasks and discussions. Switch by genre to focus on what you want to compare.

Benchmark Genres

Model Directory

System Design

Anthropic Claude Opus 4.6 VS Google Gemini 2.5 Pro

Design a Global URL Shortening Service

Design a public URL shortening service similar to Bitly. The service must let users create short links for long URLs, optionally specify a custom alias if available, and redirect users who visit the short link to the original destination. Include a basic analytics feature that reports total clicks per link and clicks by day for the last 30 days. Assume the following constraints: - 120 million new short links are created per month. - 1.2 billion redirect requests are served per month. - Read traffic is highly bursty, especially for viral links. - The service is used globally and users expect low-latency redirects. - Short links should remain valid for at least 5 years. - Redirect availability target is 99.99 percent. - Analytics may be eventually consistent by up to 10 minutes. - The system should prevent obvious abuse at a basic level, but a full trust and safety platform is out of scope. In your design, cover: - High-level architecture and main components. - Data model and storage choices for link mappings and analytics. - ID or token generation strategy, including custom alias handling. - API design for creating links, redirecting, and fetching analytics. - Caching, partitioning, and replication strategy. - Reliability approach, including failure handling and multi-region considerations. - How you would scale for read-heavy traffic and viral hotspots. - Key trade-offs in consistency, cost, latency, and operational complexity. State any reasonable assumptions you make and justify your choices.

62
Mar 19, 2026 08:02

System Design

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

Design a Global URL Shortening Service

Design a public URL shortening service similar to Bitly. Users can submit a long URL and receive a short alias, then anyone can use the short link to be redirected to the original URL. Your design should support these requirements and constraints: Functional requirements: - Create short links for arbitrary valid URLs. - Redirect short links with low latency. - Support optional custom aliases when available. - Provide basic click analytics per link: total clicks, clicks in the last 24 hours, and top 5 countries by click count. - Allow link expiration dates. Scale assumptions: - 120 million new short links per day. - 8 billion redirect requests per day. - Read-heavy workload with strong traffic skew: a small fraction of links receive very high traffic. - Global users across North America, Europe, and Asia. Constraints: - 99.99% availability target for redirects. - P95 redirect latency under 80 ms for users in major regions. - Newly created links should become usable within 2 seconds globally. - Analytics can be eventually consistent, but redirects must be correct. - Budget matters: justify where you would spend on stronger consistency or multi-region replication and where you would avoid it. - Assume no third-party managed analytics product; design the core system yourself. Please provide: - A high-level architecture with major components and data flow. - Storage choices for link mappings, analytics events, and cached hot links. - ID generation or alias strategy, including collision handling and custom alias checks. - API design for create-link, redirect, and analytics retrieval. - Scaling approach for hot keys, caching, partitioning, and multi-region traffic. - Reliability strategy covering failover, data replication, backup, and degradation behavior. - Key trade-offs and at least two alternative design choices you considered and rejected.

53
Mar 19, 2026 04:33

System Design

Google Gemini 2.5 Pro VS OpenAI GPT-5 mini

Design a URL Shortening Service at Scale

You are tasked with designing a URL shortening service (similar to bit.ly or tinyurl.com) that must handle the following constraints: 1. The service must support 100 million new URL shortenings per month. 2. The read-to-write ratio is 100:1 (i.e., 10 billion redirects per month). 3. Shortened URLs must be at most 7 characters long (alphanumeric). 4. The system must guarantee that a shortened URL, once created, never expires unless explicitly deleted by the user. 5. Redirect latency (from receiving the request to issuing the HTTP 301/302) must be under 10 milliseconds at the 99th percentile. 6. The system must remain available even if an entire data center goes offline. 7. The service must support an optional analytics dashboard showing click counts, geographic distribution, and referrer data per shortened URL, but analytics must not degrade redirect performance. Provide a comprehensive system design that addresses: A. High-level architecture: Describe the major components and how they interact. B. URL generation strategy: How you generate unique short codes, why you chose that approach, and how you handle collisions. C. Data model and storage: What databases or storage systems you use and why. Include schema considerations. D. Read path optimization: How you achieve the latency requirement for redirects at the given scale. E. Write path: How new URLs are created and persisted reliably. F. Scaling strategy: How the system scales horizontally to handle growth. G. Reliability and fault tolerance: How you handle data center failures, replication, and failover. H. Analytics pipeline: How you collect, process, and serve analytics data without impacting redirect performance. I. Key trade-offs: Identify at least three significant trade-offs you made in your design and justify each one. Be specific about technologies, protocols, and numerical estimates where relevant (e.g., storage calculations, QPS estimates, cache sizes).

50
Mar 18, 2026 22:59

System Design

OpenAI GPT-5.2 VS Google Gemini 2.5 Pro

Design a URL Shortening Service

Design a URL shortening service similar to bit.ly or TinyURL. Your design should address the following aspects: 1. **Functional Requirements**: What are the core features the service must support? Consider URL creation, redirection, expiration, and analytics. 2. **High-Level Architecture**: Describe the main components of the system (e.g., API layer, application servers, databases, caches, load balancers). Explain how they interact. 3. **URL Encoding Strategy**: How will you generate short, unique keys for each URL? Discuss your approach (e.g., hashing, base62 encoding, pre-generated key service) and how you handle collisions. 4. **Database Design**: What database(s) would you use and why? Provide the schema for the core table(s). Discuss the trade-offs between SQL and NoSQL for this use case. 5. **Scalability and Performance**: How would you handle high read traffic (e.g., millions of redirects per day)? Discuss caching strategy, database partitioning or sharding, and read replicas. 6. **Reliability and Availability**: How do you ensure the service remains available if a component fails? Discuss redundancy, replication, and failover strategies. 7. **Rate Limiting and Abuse Prevention**: How would you prevent misuse of the service? Provide a clear, well-structured plan that a senior engineer could use as a starting point for implementation. Include rough capacity estimations assuming 100 million new URLs per month and a 100:1 read-to-write ratio.

70
Mar 11, 2026 17:55

Related Links

X f L