System Design Deep Dive ·

🎯 Design Auction System

1️⃣ Core Framework

When discussing Auction System design, I frame it as:

Auction listing and item model
Bidding flow
Auction state machine
Real-time bid updates
Winner selection
Payment and settlement
Anti-sniping and fraud prevention
Consistency, scaling, and failure handling

2️⃣ Core Requirements

Functional Requirements

Seller can create auction
Buyer can place bid
Users can view current highest bid
Support auction start and end time
Support reserve price
Support bid increment rules
Support real-time bid updates
Select winner when auction ends
Support payment after winning
Support cancellation and dispute handling

Non-functional Requirements

Low-latency bid submission
Strong correctness for bid ordering
Prevent double winner
Prevent invalid bids
High availability for browsing
Auditable bid history
Real-time notifications
Stronger consistency for final winner selection

👉 Interview Answer

An auction system manages competitive bidding for limited items.

The most important challenge is handling concurrent bids correctly, especially near auction end time.

I would separate read-heavy auction browsing from write-critical bid placement and winner selection.

3️⃣ Core Concepts

Auction

An auction has:

Item
Seller
Start time
End time
Current highest bid
Reserve price
Auction status

Bid

A bid has:

Bidder
Auction ID
Bid amount
Timestamp
Status

Reserve Price

Minimum price required for the auction to succeed.

Bid Increment

Minimum increase over current highest bid.

Example:

current highest bid = $100
minimum increment = $5
next valid bid >= $105

👉 Interview Answer

I would model the system around auctions and bids.

Each auction has a time window, reserve price, current highest bid, and state.

Each bid must be validated against auction status, end time, current highest bid, and minimum increment rules.

4️⃣ Main APIs

Create Auction

POST /api/auctions

Request:

{
  "sellerId": "s123",
  "itemId": "i456",
  "startTime": "2026-06-01T10:00:00Z",
  "endTime": "2026-06-01T11:00:00Z",
  "reservePrice": 10000,
  "minimumIncrement": 500
}

Get Auction

GET /api/auctions/{auctionId}

Place Bid

POST /api/auctions/{auctionId}/bids

Request:

{
  "bidderId": "u123",
  "amount": 15000
}

Headers:

Idempotency-Key: bid-u123-a789-001

Get Bid History

GET /api/auctions/{auctionId}/bids

Close Auction

POST /api/auctions/{auctionId}/close

👉 Interview Answer

The most critical API is place bid.

It must validate the bid atomically, update the highest bid if valid, and record bid history.

Bid APIs must be idempotent because clients may retry after timeout.

5️⃣ Data Model

Auction Table

auction (
  auction_id VARCHAR PRIMARY KEY,
  seller_id VARCHAR,
  item_id VARCHAR,
  start_time TIMESTAMP,
  end_time TIMESTAMP,
  reserve_price BIGINT,
  minimum_increment BIGINT,
  current_highest_bid BIGINT,
  current_winner_id VARCHAR,
  status VARCHAR, -- scheduled, active, closing, closed, cancelled
  version BIGINT,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

Bid Table

bid (
  bid_id VARCHAR PRIMARY KEY,
  auction_id VARCHAR,
  bidder_id VARCHAR,
  amount BIGINT,
  status VARCHAR, -- accepted, rejected, outbid, winning
  idempotency_key VARCHAR,
  created_at TIMESTAMP
)

Auction Event Table

auction_event (
  event_id VARCHAR PRIMARY KEY,
  auction_id VARCHAR,
  event_type VARCHAR,
  actor_id VARCHAR,
  created_at TIMESTAMP,
  metadata JSON
)

Payment Table

auction_payment (
  payment_id VARCHAR PRIMARY KEY,
  auction_id VARCHAR,
  winner_id VARCHAR,
  amount BIGINT,
  status VARCHAR,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

👉 Interview Answer

I would store auction state, bid history, auction events, and payment records separately.

The auction row stores the current highest bid for fast reads, while the bid table stores the full immutable bid history for auditability.

6️⃣ Auction State Machine

Common States

SCHEDULED
ACTIVE
CLOSING
CLOSED
CANCELLED
PAYMENT_PENDING
PAID
FAILED

State Transitions

SCHEDULED → ACTIVE
ACTIVE → CLOSING
CLOSING → CLOSED
CLOSED → PAYMENT_PENDING
PAYMENT_PENDING → PAID

Why State Machine Matters

Prevent bids after auction ends
Prevent closing twice
Prevent multiple winners
Coordinate payment
Support cancellation and disputes

👉 Interview Answer

I would model auction lifecycle as a state machine.

This prevents invalid transitions, such as accepting bids after close, closing an auction multiple times, or creating multiple winners.

7️⃣ Bid Placement Flow

Basic Flow

User submits bid
→ Validate auction is active
→ Validate current time < end time
→ Validate bid amount >= current highest bid + increment
→ Atomically update highest bid
→ Insert bid record
→ Mark previous winner as outbid
→ Publish bid accepted event
→ Notify participants

Atomic Update

UPDATE auction
SET current_highest_bid = 15000,
    current_winner_id = 'u123',
    version = version + 1
WHERE auction_id = 'a789'
AND status = 'ACTIVE'
AND end_time > now()
AND current_highest_bid + minimum_increment <= 15000;

Why Atomic?

Because many users may bid at the same time.

Only one highest bid should win.

👉 Interview Answer

Bid placement must be atomic.

I would use a conditional update on the auction row to ensure the auction is still active and the new bid is higher than the current highest bid plus increment.

If the update succeeds, the bid is accepted; otherwise, the bid is rejected or retried with the latest price.

8️⃣ Concurrency and Ordering

Problem

Multiple bids can arrive at nearly the same time.

Example:

Bid A: $100 at 10:00:01.001
Bid B: $110 at 10:00:01.002
Bid C: $105 at 10:00:01.003

Ordering Rules

Usually ordered by:

Higher amount wins
If same amount, earlier timestamp wins

Techniques

Conditional update
Optimistic locking
Row-level locking
Single-writer per auction
Event log ordering

Hot Auctions

For extremely popular auctions:

auction_id → single partition / actor / queue

This serializes bids.

👉 Interview Answer

For normal auctions, conditional updates or optimistic locking can handle concurrent bids.

For very hot auctions, I would route all bids for the same auction to a single partition or actor so bids are processed in a deterministic order.

9️⃣ Real-time Updates

What to Push?

New highest bid
User outbid
Auction ending soon
Auction extended
Auction closed
Winner selected

Flow

Bid accepted
→ Event published
→ Notification service
→ WebSocket / SSE push
→ Clients update auction page

Protocol

Use:

WebSocket
Server-sent events
Push notifications
Polling fallback

👉 Interview Answer

Users expect real-time bid updates.

After a bid is accepted, the system publishes an event, and connected clients receive updates through WebSocket or server-sent events.

Real-time UI can be eventually consistent, but bid acceptance must be strongly correct.

🔟 Anti-sniping

What Is Sniping?

A bidder places a bid at the last second, leaving others no time to respond.

Strategy: Extend Auction

If a bid arrives near the end:

if bid_time within last 2 minutes:
    extend auction by 2 minutes

Benefits

Fairer bidding
More seller revenue
Better user experience

Design

Auction end time update must be atomic with bid acceptance.

👉 Interview Answer

To prevent sniping, I would support automatic auction extension.

If a valid bid arrives within the final time window, the system extends the auction end time.

This extension should happen atomically with bid acceptance.

1️⃣1️⃣ Proxy Bidding / Auto-bidding

What Is Proxy Bidding?

User submits maximum willingness to pay.

The system bids on their behalf.

Example:

User A max bid = $100
User B bids $60
System sets A current bid = $65

Benefits

Better user experience
Users do not need to constantly watch auction
Encourages higher final price

Data Model

proxy_bid (
  auction_id VARCHAR,
  bidder_id VARCHAR,
  max_amount BIGINT,
  created_at TIMESTAMP,
  PRIMARY KEY (auction_id, bidder_id)
)

👉 Interview Answer

Proxy bidding allows users to submit their maximum bid.

The system automatically increases their current bid only as much as needed to stay ahead.

Proxy bidding requires careful deterministic ordering because multiple max bids can compete.

1️⃣2️⃣ Winner Selection

Close Auction Flow

Auction end time reached
→ Closing worker locks auction
→ Validate auction is active
→ Check highest bid >= reserve price
→ Mark auction closed
→ Select current_winner_id
→ Create payment request
→ Notify winner and seller

No Winner Cases

No bids
Highest bid below reserve price
Auction cancelled
Winner fails payment and policy does not allow fallback

Important Rule

Winner selection must be idempotent.

👉 Interview Answer

Winner selection should be done by a closing worker.

The worker atomically transitions the auction from active to closed, verifies reserve price, selects the winner, and creates payment flow.

This process must be idempotent to avoid multiple winners.

1️⃣3️⃣ Payment and Settlement

Payment Flow

Auction closed
→ Winner selected
→ Payment intent created
→ Winner pays
→ Payment captured
→ Seller settlement scheduled
→ Item fulfillment starts

Failure Cases

Winner does not pay
Payment fails
Seller cancels
Buyer disputes
Refund required

Options

Require payment method before bidding
Pre-authorize deposit
Give winner payment deadline
Offer item to next highest bidder
Cancel auction if unpaid

👉 Interview Answer

Payment should be integrated after winner selection.

For high-value auctions, the system may require payment method validation or deposit before bidding.

If the winner fails to pay, business rules may offer the item to the next highest bidder or cancel the auction.

1️⃣4️⃣ Fraud and Abuse Prevention

Fraud Types

Fake bids
Shill bidding
Bot bidding
Bid shielding
Non-paying winners
Account takeover

Detection Signals

Same IP / device as seller
Abnormal bid patterns
New accounts bidding high
Repeated non-payment
Coordinated bidder behavior
Velocity anomalies

Strategies

Identity verification
Payment method validation
Bid limits for new users
Fraud scoring
Manual review
Account penalties

👉 Interview Answer

Fraud prevention is important because auctions can be manipulated.

I would detect suspicious bidding patterns, enforce payment method validation, limit new accounts, and use fraud scoring to catch shill bidding, bot bidding, and non-paying winners.

1️⃣5️⃣ Read Model and Caching

Read-heavy Data

Auction detail page
Current highest bid
Bid count
Time remaining
Item metadata
Watchlist

Cache Strategy

Cache auction metadata
Cache item details
Cache current highest bid carefully
Use real-time events for updates
Revalidate on bid submission

Important Rule

Cached price is for display only.

Bid validation must use authoritative auction state.

👉 Interview Answer

Auction pages are read-heavy, so I would cache auction metadata and item details.

But bid submission must always validate against the authoritative auction state, not cached data.

Cached highest bid is only for display.

1️⃣6️⃣ Scaling Patterns

Pattern 1: Separate Read and Write Paths

Read path: cached auction pages
Write path: authoritative bid processing

Pattern 2: Shard by Auction ID

hash(auction_id)

Pattern 3: Single-writer for Hot Auctions

Serialize bids for one auction.

Pattern 4: Event-driven Updates

bid accepted
→ update read model
→ notify watchers
→ analytics

Pattern 5: Delayed Closing Jobs

Auction closing workers process auctions by end time.

👉 Interview Answer

To scale auctions, I would shard by auction ID, separate read-heavy auction browsing from write-critical bid placement, and use single-writer processing for hot auctions.

Bid events update read models and notify users asynchronously.

1️⃣7️⃣ Failure Handling

Common Failures

Bid request timeout
Duplicate bid request
Bid accepted but notification fails
Auction closing worker delayed
Payment fails after winning
Cache shows stale bid
Hot auction overload
WebSocket disconnects

Strategies

Idempotency keys
Conditional updates
Retry closing worker
Outbox pattern for events
Reconciliation job for ended auctions
Fallback polling for real-time updates
Queue-based processing for hot auctions

👉 Interview Answer

Auction systems must handle partial failures carefully.

Bid placement should be idempotent and protected by conditional updates.

If notifications fail, the bid is still valid because auction state is authoritative.

If closing workers are delayed, a reconciliation job can close expired auctions.

1️⃣8️⃣ Consistency Model

Stronger Consistency Needed For

Bid acceptance
Highest bid update
Winner selection
Auction closing
Payment
Fraud-sensitive actions

Eventual Consistency Acceptable For

Auction browsing
Bid count display
Notifications
Analytics
Watchlist updates
Search indexing

👉 Interview Answer

Auction systems require mixed consistency.

Bid acceptance, highest bid, auction closing, and winner selection need strong correctness.

Browsing pages, notifications, analytics, and search indexing can be eventually consistent.

1️⃣9️⃣ Observability

Key Metrics

Bid submission latency
Bid success rate
Bid rejection rate
Highest bid update failures
Auction close delay
Double winner count
Payment failure rate
WebSocket delivery lag
Hot auction QPS
Fraud detection rate

👉 Interview Answer

I would monitor bid latency, bid success and rejection rates, auction close delay, payment failures, WebSocket delivery lag, hot auction QPS, and any double-winner incidents.

These metrics reflect both correctness and user experience.

2️⃣0️⃣ End-to-End Flow

Auction Creation Flow

Seller creates auction
→ Validate item and seller
→ Create auction in scheduled state
→ Start-time worker activates auction
→ Auction becomes visible

Bidding Flow

Buyer submits bid
→ Validate auction active
→ Validate amount
→ Atomic highest bid update
→ Insert bid record
→ Publish bid accepted event
→ Notify previous and current bidders

Closing Flow

Auction reaches end time
→ Closing worker locks auction
→ Validate reserve price
→ Select winner
→ Mark auction closed
→ Start payment flow
→ Notify winner and seller

Key Insight

Auction System is not just a bidding page — it is a concurrency-sensitive state machine for competitive allocation.

🧠 Staff-Level Answer (Final)

👉 Interview Answer (Full Version)

When designing an auction system, I think of it as a concurrency-sensitive allocation system.

The system manages auctions, bids, winner selection, payment, and settlement.

The most important requirement is correctness of bid acceptance and winner selection.

Auction browsing is read-heavy and can use cached read models, but bid placement must always use authoritative auction state.

When a user places a bid, the system validates that the auction is active, the current time is before the end time, and the bid amount satisfies the minimum increment.

Then it atomically updates the current highest bid using a conditional update or single-writer processing.

For hot auctions, I would route all bids for the same auction to a single partition or actor to guarantee deterministic ordering.

I would model auction lifecycle as a state machine with states like scheduled, active, closing, closed, payment pending, paid, and cancelled.

Winner selection should be handled by an idempotent closing worker that verifies the reserve price, closes the auction, selects the winner, and starts payment.

Real-time bid updates can be pushed through WebSocket or SSE, but UI updates can be eventually consistent.

Payment and fraud prevention are critical, especially for high-value auctions.

The main trade-offs are bid latency, consistency, fairness, scalability, real-time user experience, and fraud risk.

Ultimately, the goal is to process bids quickly, prevent invalid or duplicate winners, and select the correct winner with a full audit trail.

⭐ Final Insight

Auction System 的核心不是简单出价，而是一个高并发下保证 bid ordering、winner selection 和 payment correctness 的竞争性资源分配系统。

中文部分

🎯 Design Auction System

1️⃣ 核心框架

在设计 Auction System 时，我通常从以下几个方面分析：

Auction listing 和 item model
Bidding flow
Auction state machine
Real-time bid updates
Winner selection
Payment and settlement
Anti-sniping 和 fraud prevention
Consistency、scaling 和 failure handling

2️⃣ 核心需求

功能需求

Seller 可以创建 auction
Buyer 可以出价
用户可以查看当前最高价
支持 auction start time 和 end time
支持 reserve price
支持 bid increment rules
支持实时 bid updates
Auction 结束后选出 winner
支持 winner payment
支持 cancellation 和 dispute handling

非功能需求

Bid submission 低延迟
Bid ordering 强正确性
防止 double winner
防止 invalid bids
Auction browsing 高可用
Bid history 可审计
实时通知
Final winner selection 需要强一致

👉 面试回答

Auction System 管理的是有限 item 的竞争性出价。

最重要的挑战是正确处理并发 bids，尤其是在 auction 快结束时。

我会将 read-heavy 的 auction browsing 和 write-critical 的 bid placement / winner selection 分开。

3️⃣ 核心概念

Auction

Auction 包含：

Item
Seller
Start time
End time
Current highest bid
Reserve price
Auction status

Bid

Bid 包含：

Bidder
Auction ID
Bid amount
Timestamp
Status

Reserve Price

Reserve price 是 auction 成功所需的最低价格。

Bid Increment

Bid increment 是相对于当前最高价的最小加价。

示例：

current highest bid = $100
minimum increment = $5
next valid bid >= $105

👉 面试回答

我会围绕 auction 和 bid 建模。

每个 auction 有时间窗口、reserve price、 current highest bid 和 state。

每个 bid 都必须根据 auction status、end time、 current highest bid 和 minimum increment rules 进行校验。

4️⃣ 主要 API

Create Auction

POST /api/auctions

Request:

{
  "sellerId": "s123",
  "itemId": "i456",
  "startTime": "2026-06-01T10:00:00Z",
  "endTime": "2026-06-01T11:00:00Z",
  "reservePrice": 10000,
  "minimumIncrement": 500
}

Get Auction

GET /api/auctions/{auctionId}

Place Bid

POST /api/auctions/{auctionId}/bids

Request:

{
  "bidderId": "u123",
  "amount": 15000
}

Headers:

Idempotency-Key: bid-u123-a789-001

Get Bid History

GET /api/auctions/{auctionId}/bids

Close Auction

POST /api/auctions/{auctionId}/close

👉 面试回答

最关键的 API 是 place bid。

它必须原子校验 bid，如果有效则更新 highest bid，并记录 bid history。

Bid API 必须幂等，因为 client 可能在 timeout 后重试。

5️⃣ 数据模型

Auction Table

auction (
  auction_id VARCHAR PRIMARY KEY,
  seller_id VARCHAR,
  item_id VARCHAR,
  start_time TIMESTAMP,
  end_time TIMESTAMP,
  reserve_price BIGINT,
  minimum_increment BIGINT,
  current_highest_bid BIGINT,
  current_winner_id VARCHAR,
  status VARCHAR, -- scheduled, active, closing, closed, cancelled
  version BIGINT,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

Bid Table

bid (
  bid_id VARCHAR PRIMARY KEY,
  auction_id VARCHAR,
  bidder_id VARCHAR,
  amount BIGINT,
  status VARCHAR, -- accepted, rejected, outbid, winning
  idempotency_key VARCHAR,
  created_at TIMESTAMP
)

Auction Event Table

auction_event (
  event_id VARCHAR PRIMARY KEY,
  auction_id VARCHAR,
  event_type VARCHAR,
  actor_id VARCHAR,
  created_at TIMESTAMP,
  metadata JSON
)

Payment Table

auction_payment (
  payment_id VARCHAR PRIMARY KEY,
  auction_id VARCHAR,
  winner_id VARCHAR,
  amount BIGINT,
  status VARCHAR,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

👉 面试回答

我会将 auction state、bid history、 auction events 和 payment records 分开存储。

Auction row 存储 current highest bid，用于快速读取； bid table 存储完整 immutable bid history，用于 auditability。

6️⃣ Auction State Machine

Common States

SCHEDULED
ACTIVE
CLOSING
CLOSED
CANCELLED
PAYMENT_PENDING
PAID
FAILED

State Transitions

SCHEDULED → ACTIVE
ACTIVE → CLOSING
CLOSING → CLOSED
CLOSED → PAYMENT_PENDING
PAYMENT_PENDING → PAID

Why State Machine Matters

防止 auction 结束后继续出价
防止重复 close
防止多个 winners
协调 payment
支持 cancellation 和 disputes

👉 面试回答

我会将 auction lifecycle 建模成 state machine。

这样可以防止非法状态转换，例如 auction close 后仍接受 bid、重复关闭 auction，或创建多个 winners。

7️⃣ Bid Placement Flow

Basic Flow

User submits bid
→ Validate auction is active
→ Validate current time < end time
→ Validate bid amount >= current highest bid + increment
→ Atomically update highest bid
→ Insert bid record
→ Mark previous winner as outbid
→ Publish bid accepted event
→ Notify participants

Atomic Update

UPDATE auction
SET current_highest_bid = 15000,
    current_winner_id = 'u123',
    version = version + 1
WHERE auction_id = 'a789'
AND status = 'ACTIVE'
AND end_time > now()
AND current_highest_bid + minimum_increment <= 15000;

Why Atomic?

因为很多用户可能同时出价。

系统只能有一个正确最高价和 winner。

👉 面试回答

Bid placement 必须是 atomic。

我会对 auction row 使用 conditional update，确保 auction 仍然 active，并且新 bid 高于 current highest bid 加 minimum increment。

如果 update 成功，bid 被接受；否则 bid 被拒绝，或者用最新价格重试。

8️⃣ Concurrency and Ordering

Problem

多个 bids 可能几乎同时到达。

示例：

Bid A: $100 at 10:00:01.001
Bid B: $110 at 10:00:01.002
Bid C: $105 at 10:00:01.003

Ordering Rules

通常规则：

Higher amount wins
If same amount, earlier timestamp wins

Techniques

Conditional update
Optimistic locking
Row-level locking
Single-writer per auction
Event log ordering

Hot Auctions

对于极热门 auctions：

auction_id → single partition / actor / queue

这样可以串行化 bids。

👉 面试回答

对普通 auctions， conditional updates 或 optimistic locking 可以处理并发 bids。

对非常热门的 auctions，我会将同一个 auction 的所有 bids 路由到一个 partition 或 actor，从而保证 deterministic ordering。

9️⃣ Real-time Updates

What to Push?

New highest bid
User outbid
Auction ending soon
Auction extended
Auction closed
Winner selected

Flow

Bid accepted
→ Event published
→ Notification service
→ WebSocket / SSE push
→ Clients update auction page

Protocol

使用：

WebSocket
Server-sent events
Push notifications
Polling fallback

👉 面试回答

用户希望看到实时 bid updates。

当 bid 被接受后，系统发布 event， connected clients 通过 WebSocket 或 SSE 收到更新。

Real-time UI 可以最终一致，但 bid acceptance 必须强正确。

🔟 Anti-sniping

什么是 Sniping？

Bidder 在最后一秒出价，让其他人没有时间回应。

Strategy: Extend Auction

如果 bid 在结束前很短时间内到达：

if bid_time within last 2 minutes:
    extend auction by 2 minutes

Benefits

更公平
提升 seller revenue
更好的用户体验

Design

Auction end time update 必须和 bid acceptance 原子执行。

👉 面试回答

为了防止 sniping，我会支持 automatic auction extension。

如果有效 bid 在最后时间窗口内到达，系统会延长 auction end time。

这个 extension 应该和 bid acceptance 原子执行。

1️⃣1️⃣ Proxy Bidding / Auto-bidding

什么是 Proxy Bidding？

用户提交自己愿意支付的最高价。

系统代替用户自动加价。

示例：

User A max bid = $100
User B bids $60
System sets A current bid = $65

Benefits

用户体验更好
用户不需要一直盯着 auction
可能提高 final price

Data Model

proxy_bid (
  auction_id VARCHAR,
  bidder_id VARCHAR,
  max_amount BIGINT,
  created_at TIMESTAMP,
  PRIMARY KEY (auction_id, bidder_id)
)

👉 面试回答

Proxy bidding 允许用户提交最高可接受价格。

系统会自动用最低必要价格帮助用户保持领先。

Proxy bidding 需要非常谨慎的 deterministic ordering，因为多个 max bids 可能互相竞争。

1️⃣2️⃣ Winner Selection

Close Auction Flow

Auction end time reached
→ Closing worker locks auction
→ Validate auction is active
→ Check highest bid >= reserve price
→ Mark auction closed
→ Select current_winner_id
→ Create payment request
→ Notify winner and seller

No Winner Cases

No bids
Highest bid below reserve price
Auction cancelled
Winner fails payment and policy does not allow fallback

Important Rule

Winner selection 必须幂等。

👉 面试回答

Winner selection 应该由 closing worker 执行。

Worker 会原子地将 auction 从 active 转为 closed，验证 reserve price，选择 winner，并启动 payment flow。

这个过程必须幂等，防止产生多个 winners。

1️⃣3️⃣ Payment and Settlement

Payment Flow

Auction closed
→ Winner selected
→ Payment intent created
→ Winner pays
→ Payment captured
→ Seller settlement scheduled
→ Item fulfillment starts

Failure Cases

Winner does not pay
Payment fails
Seller cancels
Buyer disputes
Refund required

Options

出价前要求 payment method
Pre-authorize deposit
给 winner payment deadline
Offer item to next highest bidder
Unpaid 时 cancel auction

👉 面试回答

Payment 应该在 winner selection 后集成。

对高价值 auctions，系统可以在 bidding 前验证 payment method 或要求 deposit。

如果 winner 不付款，业务规则可以将 item 提供给第二高 bidder，或取消 auction。

1️⃣4️⃣ Fraud and Abuse Prevention

Fraud Types

Fake bids
Shill bidding
Bot bidding
Bid shielding
Non-paying winners
Account takeover

Detection Signals

和 seller 相同 IP / device
异常 bid patterns
新账号高额出价
重复不付款
协同 bidder behavior
Velocity anomalies

Strategies

Identity verification
Payment method validation
Bid limits for new users
Fraud scoring
Manual review
Account penalties

👉 面试回答

Fraud prevention 很重要，因为 auctions 很容易被操纵。

我会检测可疑 bidding patterns，强制 payment method validation，对新账号设置 bid limits，并使用 fraud scoring 识别 shill bidding、 bot bidding 和 non-paying winners。

1️⃣5️⃣ Read Model and Caching

Read-heavy Data

Auction detail page
Current highest bid
Bid count
Time remaining
Item metadata
Watchlist

Cache Strategy

Cache auction metadata
Cache item details
谨慎缓存 current highest bid
使用 real-time events 更新 UI
Bid submission 时重新验证

Important Rule

Cached price 只用于展示。

Bid validation 必须使用 authoritative auction state。

👉 面试回答

Auction pages 是 read-heavy，所以我会缓存 auction metadata 和 item details。

但 bid submission 必须总是基于 authoritative auction state 校验，不能依赖 cached data。

Cached highest bid 只能用于展示。

1️⃣6️⃣ Scaling Patterns

Pattern 1: Separate Read and Write Paths

Read path: cached auction pages
Write path: authoritative bid processing

Pattern 2: Shard by Auction ID

hash(auction_id)

Pattern 3: Single-writer for Hot Auctions

对同一个 auction 串行化 bids。

Pattern 4: Event-driven Updates

bid accepted
→ update read model
→ notify watchers
→ analytics

Pattern 5: Delayed Closing Jobs

Auction closing workers 按 end time 处理 auctions。

👉 面试回答

为了扩展 auctions，我会按 auction ID 分片，将 read-heavy auction browsing 和 write-critical bid placement 分开。

对热门 auctions，使用 single-writer processing。

Bid events 会异步更新 read models 并通知用户。

1️⃣7️⃣ Failure Handling

Common Failures

Bid request timeout
Duplicate bid request
Bid accepted but notification fails
Auction closing worker delayed
Payment fails after winning
Cache shows stale bid
Hot auction overload
WebSocket disconnects

Strategies

Idempotency keys
Conditional updates
Retry closing worker
Outbox pattern for events
Reconciliation job for ended auctions
Fallback polling for real-time updates
Queue-based processing for hot auctions

👉 面试回答

Auction system 必须谨慎处理 partial failures。

Bid placement 应该幂等，并由 conditional updates 保护。

如果 notification 失败， bid 仍然有效，因为 auction state 才是 authoritative。

如果 closing worker 延迟， reconciliation job 可以关闭已经过期的 auctions。

1️⃣8️⃣ Consistency Model

需要较强一致性的场景

Bid acceptance
Highest bid update
Winner selection
Auction closing
Payment
Fraud-sensitive actions

可以最终一致的场景

Auction browsing
Bid count display
Notifications
Analytics
Watchlist updates
Search indexing

👉 面试回答

Auction system 需要 mixed consistency。

Bid acceptance、highest bid、auction closing 和 winner selection 需要强正确性。

Browsing pages、notifications、analytics 和 search indexing 可以最终一致。

1️⃣9️⃣ Observability

Key Metrics

Bid submission latency
Bid success rate
Bid rejection rate
Highest bid update failures
Auction close delay
Double winner count
Payment failure rate
WebSocket delivery lag
Hot auction QPS
Fraud detection rate

👉 面试回答

我会监控 bid latency、bid success / rejection rates、 auction close delay、payment failures、 WebSocket delivery lag、hot auction QPS 和任何 double-winner incidents。

这些指标反映 correctness 和用户体验。

2️⃣0️⃣ End-to-End Flow

Auction Creation Flow

Seller creates auction
→ Validate item and seller
→ Create auction in scheduled state
→ Start-time worker activates auction
→ Auction becomes visible

Bidding Flow

Buyer submits bid
→ Validate auction active
→ Validate amount
→ Atomic highest bid update
→ Insert bid record
→ Publish bid accepted event
→ Notify previous and current bidders

Closing Flow

Auction reaches end time
→ Closing worker locks auction
→ Validate reserve price
→ Select winner
→ Mark auction closed
→ Start payment flow
→ Notify winner and seller

Key Insight

Auction System 不是简单的 bidding page，而是一个 concurrency-sensitive state machine for competitive allocation。

🧠 Staff-Level Answer（最终版）

👉 面试回答（完整背诵版）

在设计 Auction System 时，我会把它看作一个 concurrency-sensitive allocation system。

系统管理 auctions、bids、winner selection、 payment 和 settlement。

最重要的需求是 bid acceptance 和 winner selection 的正确性。

Auction browsing 是 read-heavy，可以使用 cached read models；但 bid placement 必须始终使用 authoritative auction state。

当用户出价时，系统会验证 auction 是否 active，当前时间是否在 end time 之前，以及 bid amount 是否满足 minimum increment。

然后系统通过 conditional update 或 single-writer processing 原子更新 current highest bid。

对 hot auctions，我会将同一个 auction 的所有 bids 路由到单一 partition 或 actor，保证 deterministic ordering。

我会将 auction lifecycle 建模成 state machine，包括 scheduled、active、closing、closed、 payment pending、paid 和 cancelled 等状态。

Winner selection 应该由幂等 closing worker 处理，负责验证 reserve price、关闭 auction、选择 winner 并启动 payment。

Real-time bid updates 可以通过 WebSocket 或 SSE 推送，但 UI updates 可以最终一致。

Payment 和 fraud prevention 对高价值 auctions 非常关键。

核心权衡包括 bid latency、consistency、fairness、 scalability、real-time user experience 和 fraud risk。

最终目标是快速处理 bids，防止 invalid 或 duplicate winners，并通过完整 audit trail 选择正确 winner。

⭐ Final Insight

Auction System 的核心不是简单出价，而是一个高并发下保证 bid ordering、winner selection 和 payment correctness 的竞争性资源分配系统。