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

Google Gemini 2.5 Flash VS Anthropic Claude Haiku 4.5

Design a Global URL Shortening Service

Design a globally available URL shortening service similar to Bitly. The service must let users create short links that redirect to long URLs, support custom aliases for paid users, track click analytics, and allow links to expire at a specified time. Requirements: - Handle 120 million new short links per day. - Handle 4 billion redirects per day. - Peak traffic can reach 3 times the daily average. - Redirect latency target: p95 under 80 ms for users in North America, Europe, and Asia. - Short-link creation latency target: p95 under 300 ms. - Service availability target: 99.99% for redirects. - Analytics data can be eventually consistent within 5 minutes. - Custom aliases must be unique globally. - Expired or deleted links must stop redirecting quickly. - The system should tolerate regional failures without total service outage. Assumptions you may use: - Average long URL length is 500 bytes. - Analytics events include timestamp, link ID, country, device type, and referrer domain. - Read traffic is much higher than write traffic. - You may choose SQL, NoSQL, cache, stream, CDN, and messaging technologies as needed, but justify them. In your answer, provide: 1. A high-level architecture with main components and request flows. 2. Data model and storage choices for links, aliases, and analytics. 3. A scaling strategy for read-heavy traffic, including caching and regional routing. 4. A reliability strategy covering failover, consistency decisions, and handling regional outages. 5. Key trade-offs, bottlenecks, and at least three risks with mitigations. 6. A brief capacity estimate for storage and throughput using the numbers above.

57
Mar 19, 2026 18:51

System Design

Anthropic Claude Haiku 4.5 VS Google Gemini 2.5 Flash-Lite

Design a Real-Time Ride Matching Platform

Design the backend architecture for a ride-hailing platform that matches riders with nearby drivers in real time across multiple cities. Your design should support these product requirements: - Riders can request a trip by sending pickup and destination locations. - Nearby available drivers should receive the request quickly, and one driver can accept it. - The system must prevent double-booking of drivers. - Riders and drivers should see live trip status updates such as requested, accepted, arrived, in progress, and completed. - The platform should provide an estimated fare and estimated pickup time before confirmation. - Trip history should be available to both riders and drivers. Constraints and assumptions: - 8 million daily ride requests. - Peak load is 25 times the average request rate during commuting windows. - Operates in 40 cities, with uneven traffic distribution. - Location updates from active drivers arrive every 3 seconds. - Acceptable rider-facing latency for initial driver matching is under 2 seconds at p95. - Trip status updates should usually appear within 1 second. - The system should remain available during a regional service outage affecting one data center. - Exact payment processing details are out of scope, but trip records must be durable for later billing. - Privacy, security, and regulatory concerns may be mentioned briefly, but the main focus is architecture and scaling. In your answer, describe: - The main services or components and their responsibilities. - The data flow from ride request to driver assignment to trip completion. - How you would store and query driver locations efficiently. - How you would handle scaling for peak traffic and hotspot cities. - How you would ensure reliability, fault tolerance, and data consistency where it matters. - Key trade-offs in your design, including any places where you prefer eventual consistency over strong consistency, or vice versa. You do not need to provide exact cloud vendor products. A clear architecture and reasoning-focused design is preferred over exhaustive implementation detail.

61
Mar 19, 2026 07:43

Related Links

X f L