Design Postman

Reference Answer

Review the Databases, Message Queues, and Caching building blocks for background on storing hierarchical data, event-driven execution, and low-latency lookups.

Problem Statement

Design an API development and testing platform like Postman that allows users to create and organize API requests into collections, manage environment-specific variables, send HTTP requests to external servers, and write automated test scripts against responses.

Postman is a collaborative developer tool where engineers build HTTP requests, group them into collections, parameterize them with environment variables, and automate response assertions. Teams use it to explore APIs, debug integration issues, share request collections, mock endpoints, and run scheduled monitors against staging and production systems. The platform supports both a desktop application and a web interface, with real-time synchronization across devices and team members.

Interviewers ask this question because it blends document-like data management (collections, environments), a request execution engine (sending HTTP requests and running scripts), real-time collaboration, and security-sensitive features (secrets management, auth tokens, audit logging). It tests your ability to separate control-plane metadata from data-plane execution, handle collaborative editing, scale automated runs, and build safe multi-tenant systems.

Key Requirements

Functional

• Request builder -- Users construct HTTP/HTTPS requests with custom headers, query parameters, authentication tokens, and bodies in multiple formats (JSON, XML, form-data)
• Collections and organization -- Users group related requests into folders and collections with nested hierarchies and version control
• Environment management -- Users define variable sets for different environments (dev, staging, production) and switch between them when executing requests
• Test scripts and automation -- Users write JavaScript test scripts that validate response status, headers, and body; scripts can chain requests where outputs feed into subsequent calls
• Collaboration -- Teams share collections, track changes, leave comments, and manage role-based access controls at workspace and collection levels

Non-Functional

• Scalability -- Support millions of active users with hundreds of thousands of concurrent API executions during peak hours
• Reliability -- 99.9 percent uptime with fault-tolerant architecture and automatic failover
• Latency -- Request proxying adds less than 100ms overhead; UI operations complete within 200ms
• Consistency -- Eventual consistency for collection syncing across devices; strong consistency for environment variables during request execution

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Request Execution Architecture

The platform acts as an intermediary that sends user-constructed requests to external servers, captures responses, and runs test assertions. Designing this execution pipeline with proper security, timeout handling, and telemetry capture is the core engineering challenge.

Hints to consider:

• Decide whether requests execute client-side (desktop app calls external APIs directly) or server-side (cloud proxy) and discuss the security implications of each
• For server-side execution, sandbox outbound traffic to prevent SSRF attacks and restrict access to internal networks
• Capture detailed timing breakdowns (DNS lookup, TCP handshake, TLS negotiation, server processing, content transfer) to provide Postman-style performance insights
• Handle long-running requests and timeouts gracefully without blocking worker threads

2. Data Model for Collections and Environments

Collections contain deeply nested hierarchies of folders, requests, pre-request scripts, test assertions, and variable references. The schema must be flexible enough for versioning, forking, and fast retrieval.

Hints to consider:

• Use a document-oriented model where each collection is a tree of typed nodes (folder, request, script) with parent pointers for efficient traversal
• Store collections in a relational database (Postgres) with JSONB columns for the request body and script content, keeping metadata in queryable relational columns
• Version each collection edit as an immutable snapshot or operation log entry to support undo, history browsing, and fork/merge workflows
• Separate hot data (active collections, frequently accessed environments) from cold data (execution history, archived versions)

3. Real-Time Collaboration and Sync

Team members expect their collection edits to appear instantly on colleagues' screens and to sync across their own web and desktop clients, even after periods of offline work.

Hints to consider:

• Use WebSocket connections to push change notifications to all clients viewing the same workspace or collection
• Implement conflict resolution using version vectors or operational transformation when multiple users edit the same collection simultaneously
• Design an offline-first client that queues changes locally and reconciles with the server on reconnection
• Separate ephemeral collaboration state (cursor positions, active editors) from durable content changes

4. Scripting Engine and Sandbox Security

Users write JavaScript test scripts that execute against live API responses. Untrusted code execution in a multi-tenant environment demands strict sandboxing.

Hints to consider:

• Run user scripts in isolated V8 engine instances (similar to Cloudflare Workers or Node.js vm2) with CPU time limits, memory caps, and no filesystem or network access
• Provide a scoped API within the sandbox that exposes environment variables, response data, and assertion helpers without leaking host resources
• Design variable scoping so scripts can read and write global, collection-level, and environment-level variables with clear precedence rules
• For CI/CD integration, expose a CLI runner that executes collections in sequence with pre-request and post-response hooks

5. Automated Test Suites and Scheduled Runs

Teams run entire collections as automated test suites, either on demand or on a cron schedule, and expect results dashboards with pass/fail status and historical trends.

Hints to consider:

• Model test suite runs as long-running jobs: enqueue them to a durable task queue, execute requests sequentially (or in parallel where dependencies allow), and record results
• Implement idempotent job execution so retries after a crash do not re-send requests that already succeeded
• Store run results in a time-series or append-optimized database for historical dashboards and trend analysis
• Auto-scale the execution worker fleet based on queue depth to handle bursts of scheduled runs

Suggested Approach

Step 1: Clarify Requirements

Confirm whether the focus should be on individual developer workflows or enterprise team collaboration. Ask about expected scale (users, requests per second, collection sizes), whether real-time collaboration is a must-have, and whether the system needs to support mock servers, API documentation generation, or monitoring. Clarify whether request execution happens client-side, server-side, or both.

Step 2: High-Level Architecture

Sketch the major components: a client application layer (web and desktop), an API gateway for routing and authentication, a collection service managing CRUD operations for requests, folders, and environments, a request executor service handling API call proxying or dispatching, a sync service managing real-time updates across devices via WebSocket, a scripting engine with sandboxed execution, a storage layer with Postgres for collections and permissions and a time-series store for execution history, and a Kafka-backed task queue for automated test runs. Include a CDN for static assets and a Redis cache for hot collections and environment variables.

Step 3: Deep Dive on Request Execution

Walk through what happens when a user clicks "Send." The client validates the request metadata locally, resolves environment variable placeholders, runs the pre-request script in a local sandbox, and then either sends the HTTP request directly (desktop mode) or forwards it to the cloud executor service (web mode). The executor constructs the final HTTP request, applies authentication headers, sends it to the target server, and captures the full response including timing metrics. The post-response test script runs in a sandboxed runtime, and the complete execution record (request, response, timing, test results) is persisted to the history store. For automated runs, the same pipeline executes but is driven by a job scheduler that reads collections from the database and feeds requests to workers.

Step 4: Address Collaboration, Security, and Scale

Explain real-time sync through WebSocket connections and a Redis Pub/Sub layer that broadcasts edits to all clients in the same workspace. For conflict resolution, use last-write-wins with version vectors or operational transforms for concurrent edits. Cover security by encrypting secrets at rest, masking sensitive headers in logs, and enforcing RBAC at the workspace and collection level. Address scaling by deploying executor services across multiple regions with auto-scaling based on queue depth, and rate-limiting per user and workspace to prevent abuse. Store execution history with configurable retention policies and compress older records. Mention monitoring: track request execution latency, test pass rates, and workspace activity to detect issues.

Real Interview Insights

Candidates at Palo Alto Networks report that the interviewer expected them to go beyond a simple CRUD application and design a proper execution plane with queued runs, concurrency control, and network isolation. The collaboration model and secret management were also probed. Be prepared to discuss how you would safely execute user-provided scripts in a multi-tenant environment without allowing one tenant's code to access another tenant's data or secrets.