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

SeniorPrefer not to say

Jun 2026

Summary

System design round at Roblox for a software engineering role, one big open-ended question about building a scheduled payments platform. The scope was massive and I don't think I covered everything they wanted, but it was a genuinely interesting problem to work through.

Questions Asked (1)

Design a scheduled payment system where users can set a future-dated payment and cancel it before it runs. Cover the APIs, data model, job scheduling, idempotency, time zone handling, failure/retry logic, consistency with the payment gateway, security and PCI compliance, scaling strategy, monitoring, disaster recovery, and capacity estimates.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

This was basically the whole interview in one question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., expected payment volume, supported currencies, time zones) to frame the design. Then walk through the system end-to-end: API design, data model, scheduling, idempotency, failure handling, and consistency with the payment gateway. Finally, address operational concerns like security, scaling, monitoring, and disaster recovery, making trade-offs explicit.

Pro tip: Emphasize idempotency and exactly-once execution as the core challenge—interviewers expect you to discuss how you prevent duplicate charges and handle race conditions between cancellation and execution. Also, proactively mention that you'd use a battle-tested scheduler like Quartz or a cloud service (e.g., AWS EventBridge) rather than building your own, showing pragmatism.

1. Clarify requirements and scope

Ask questions to understand scale (e.g., payments per day), supported payment methods, time zone requirements, and consistency guarantees. Define functional and non-functional requirements.

2. Design APIs and data model

Define RESTful endpoints for creating, retrieving, and canceling scheduled payments. Design a database schema that captures payment details, status, scheduled time, and idempotency keys.

3. Architect scheduling and execution

Choose a scheduling mechanism (e.g., cron, message queue with delayed messages, or a dedicated scheduler). Describe how jobs are triggered, how idempotency is enforced, and how time zones are handled.

4. Handle failures, retries, and consistency

Outline retry logic with exponential backoff, dead-letter queues, and reconciliation with the payment gateway. Discuss how to ensure consistency (e.g., two-phase commit, saga pattern) and handle partial failures.

5. Address operational concerns

Cover security (PCI compliance, encryption, tokenization), scaling (sharding, partitioning), monitoring (metrics, alerts), and disaster recovery (backups, multi-region). Provide capacity estimates.

Key Points to Mention

Idempotency: Use idempotency keys for API requests and ensure exactly-once execution of payments via unique transaction IDs and database constraints.
Time zone handling: Store all times in UTC, convert to user's time zone for display, and handle DST transitions carefully.
Failure/retry logic: Implement retries with exponential backoff, circuit breakers, and dead-letter queues; reconcile with payment gateway to resolve inconsistencies.
Consistency with payment gateway: Use two-phase commit or saga pattern; ensure that cancellation and execution are atomic or have compensating actions.
Security and PCI compliance: Tokenize card data, never store sensitive information, use encryption in transit and at rest, and adhere to PCI DSS.
Scaling and monitoring: Partition data by user or time, use distributed schedulers, monitor queue depths, success rates, and set up alerts for failures.

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