Openai·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

System design round at OpenAI for a software engineer role. The question was a single massive prompt covering basically every dimension of a ChatGPT-like service with preset/system-prompt management. Felt like they wanted to see how you'd prioritize under pressure rather than actually finish the whole thing.

Questions Asked (1)

Design a minimal ChatGPT-style conversational service that supports reusable system prompt presets per user and team. Cover core components, data model, APIs, session/context management, storage, scalability, multi-tenancy, safety, failure handling, extensibility, and capacity estimates for 100k DAU. Also walk through the call sequence for creating a preset and sending a message using one.

System DesignData ModelingAPI & Integrations

Author's notes

This is basically five system design questions duct-taped together.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scope, then present a high-level architecture with core components and data model. Walk through the API design and call sequences for the two key flows, and finally address scalability, multi-tenancy, safety, and failure handling with capacity estimates.

Pro tip: Emphasize idempotency and versioning for presets to handle concurrent edits and ensure reproducibility. Also, discuss how you would leverage OpenAI's existing infrastructure (e.g., rate limiting, moderation) to avoid reinventing the wheel.

1. Clarify Requirements and Scope

Ask clarifying questions about expected features, scale, latency, and compliance needs. Define the minimal viable product and non-functional requirements.

2. High-Level Architecture and Data Model

Outline core components: API gateway, auth service, preset service, conversation service, storage (SQL/NoSQL), cache, and message queue. Define entities: User, Team, Preset, Conversation, Message.

3. API Design and Call Sequences

Design RESTful APIs for preset CRUD and message sending. Walk through the sequence for creating a preset and sending a message using it, including auth, validation, and storage interactions.

4. Scalability, Multi-Tenancy, and Capacity

Discuss partitioning, sharding, caching, and async processing. Explain multi-tenancy via team isolation and resource quotas. Provide capacity estimates for 100k DAU (e.g., QPS, storage).

5. Safety, Failure Handling, and Extensibility

Cover moderation, rate limiting, and data privacy. Describe failure modes (e.g., API timeouts, DB failures) and mitigation. Suggest extension points for future features.

Key Points to Mention

Data model: Users, Teams, Presets (with versioning), Conversations, Messages; use of relational DB for metadata and blob storage for large messages.
API design: REST endpoints for preset CRUD (e.g., POST /presets, GET /presets/{id}) and message sending (POST /conversations/{id}/messages) with idempotency keys.
Session/context management: Store conversation history in a distributed cache (e.g., Redis) with TTL, and persist asynchronously to DB; use context window management to truncate or summarize.
Scalability: Horizontal scaling of stateless services, sharding by user/team ID, read replicas, and CDN for static assets; capacity estimates: 100k DAU ~ 1M messages/day, ~12 QPS average, peak 50 QPS.
Multi-tenancy: Team-based isolation with RBAC, resource quotas per team, and data segregation in storage.
Safety and failure handling: Input/output moderation, rate limiting per user/team, retries with exponential backoff, circuit breakers, and graceful degradation.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.