Design NFT Drop Scheduler - System Design | WinJob

Problem Statement: Timed NFT Collection Drops

Manifold-style drop scheduler orchestrating allowlist, public, and reveal windows without double-minting.

This section covers problem during the understanding phase for the NFT drop scheduler design.

Why interviewers probe here

Manifold, ThirdWeb, and Crossmint engineers expect you to quantify drop-minute behavior—not hand-wave "we'll use Redis."

Control plane vs data plane

Creator owns configuration and policy (who can mint when).
Collector enforces stage windows and admission tickets.
DropEngine materializes chain truth with confirmation depth ≥ 12 blocks on Base.
ChainRPC exposes read models with ≤3s indexer lag SLO.

Drop invariants (sec-01)

A wallet may hold at most one ACTIVE mint intent per drop_id (unique partial index).
Allowlist proof verified server-side before queue ticket issuance—client proof alone is insufficient.
tokenURI must reference immutable CID before broadcast; HTTP placeholders only pre-reveal.
Scheduler transitions are compare-and-swap on drops.stage_version to prevent double-open public windows.

Capacity anchors

Signal	Value	Assumption
Peak mint POST	2,400 rps	10.8k concurrent × 22% click mint/min
Metadata CDN	9.5 Gbps	50KB JSON × 180k viewers in 60s
Signer pool	48 lanes	50 tx/s/lane × 96% success
Queue tickets	1.2M	500k allowlist + 700k public lottery

Failure modes unique to problem

Hot drop shard: single drop_id saturates one Kafka partition—mitigate with per-drop topic.
Reveal leak: CDN cache serves unblurred asset early—separate bucket, signed URL TTL 300s.
Gas spike: base fee 3× in 2 blocks—pause enqueue, keep processing queued intents with bumped fees.
Sybil queue: 30% tickets from fresh wallets—velocity score + proof-of-human for public stage.

Staff+ narrative hook

Separate time scheduling (when stages open) from admission scheduling (who gets mint slots). Collapsing both into one cron job is how teams ship double-mint incidents.

Deep dive (problem)

Walk the interviewer through how Creator hands off to Collector under stage invariants, then how DropEngine reconciles with ChainRPC. Mention idempotent mint intents, Merkle allowlists, and virtual waiting room when challenged on fairness.

javaOne Dark Pro

1 public final class DropSection1 {
2   public static final String TOPIC = "problem";
3   public static final int ORDER = 1;
4   public static final long PEAK_MINT_RPS = 2400L;
5 }

pythonOne Dark Pro

1 SECTION_1_TOPIC = "problem"
2 PEAK_MINT_RPS = 2400
3 CONFIRMATION_DEPTH = 12
4  
5 def stage_allows_mint(drop_stage: str, wall_clock) -> bool:
6     return drop_stage in {"ALLOWLIST", "PUBLIC"}

typescriptOne Dark Pro

1 export const SECTION_1 = { topic: 'problem', phase: 'understanding', order: 1 };
2 export function queueTicketTtlSec(stage: 'ALLOWLIST' | 'PUBLIC'): number {
3   return stage === 'PUBLIC' ? 90 : 120;
4 }

Why interviewers care

NFT Drop Scheduler interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Timed NFT Collection Drops that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Creator ↔ Collector boundary
•DropEngine feeds ChainRPC projections
•Phase understanding: problem focus

1	public final class DropSection1 {
2	public static final String TOPIC = "problem";
3	public static final int ORDER = 1;
4	public static final long PEAK_MINT_RPS = 2400L;
5	}

1	SECTION_1_TOPIC = "problem"
2	PEAK_MINT_RPS = 2400
3	CONFIRMATION_DEPTH = 12
4
5	def stage_allows_mint(drop_stage: str, wall_clock) -> bool:
6	return drop_stage in {"ALLOWLIST", "PUBLIC"}

1	export const SECTION_1 = { topic: 'problem', phase: 'understanding', order: 1 };
2	export function queueTicketTtlSec(stage: 'ALLOWLIST' \| 'PUBLIC'): number {
3	return stage === 'PUBLIC' ? 90 : 120;
4	}