← Commure Interview Insights

Commure·Frontend Engineer·Onsite - System Design / Architecture·Senior

Senior
Jun 2026

Summary

System design round at Commure for a frontend engineer role, which honestly skewed way more backend than I expected. The whole question was about booking flows and payment state, not a single thing about UI architecture.

Questions Asked (1)

Q1

Design a patient appointment booking system where users can browse provider timeslots, select one, and pay through a third-party payment processor. Cover the data model for timeslots, concurrency control to prevent double-booking, payment integration including webhooks and idempotency, the full booking lifecycle, and how you'd handle failures and reconciliation between booking and payment state.

System DesignAPI & IntegrationsData Modeling
Author's notes

This is a lot to cover in one question and I didn't pace myself well.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scope, then walk through the data model for timeslots and bookings, emphasizing concurrency control (e.g., optimistic locking or database constraints) to prevent double-booking. Next, explain the payment integration flow with idempotency keys and webhook handling, and finally describe the booking lifecycle state machine and failure/reconciliation strategies.

Pro tip: Emphasize idempotency and reconciliation as first-class concerns—show that you understand payments can fail or be delayed, and that the system must gracefully handle these cases without double-charging or double-booking.

1. Clarify Requirements and Scope

Ask clarifying questions about expected traffic, payment provider, and whether real-time slot locking is needed. Define the core entities and user flow.

2. Design Data Model and Concurrency Control

Propose a schema for providers, timeslots, and bookings. Explain how to prevent double-booking using database transactions, unique constraints, or optimistic locking.

3. Integrate Payment with Idempotency and Webhooks

Describe the payment flow: create a payment intent with an idempotency key, handle webhooks for asynchronous updates, and ensure idempotent processing of webhook events.

4. Define Booking Lifecycle and State Machine

Outline states (e.g., pending, confirmed, cancelled, expired) and transitions triggered by user actions or payment events. Include timeouts for pending bookings.

5. Handle Failures and Reconciliation

Explain strategies for handling payment failures, webhook delays, and discrepancies between booking and payment states, such as periodic reconciliation jobs and manual intervention.

Key Points to Mention

  • Optimistic locking or unique constraints to prevent double-booking
  • Idempotency keys for payment requests to avoid duplicate charges
  • Webhook handling with signature verification and idempotent processing
  • Booking state machine with clear transitions and timeouts
  • Reconciliation jobs to sync booking and payment states
  • Graceful degradation and user feedback for payment failures

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