Can Snowflake ID worker IDs be manually configured when scaling from two to six servers and order numbers occasionally collide?

Duplicate or clearly out-of-order Snowflake IDs are usually not caused by a wrong algorithm. They happen because the two premises the algorithm relies on are broken: time on the same machine must move monotonically forward, and worker IDs must be unique across instances. Based on common delivery experience in 2026, NTP time correction, live VM migration, and manual time changes can all make the clock jump back by tens of milliseconds to several seconds. When deployment scales from two servers to six, operations teams often copy the workerId directly from a config file; collisions are often more common than clock rollback. A fixed troubleshooting order is recommended: first confirm whether worker IDs collide, then confirm whether the clock rolled back, and only then discuss changing the ID generation scheme.

Which premises keep Snowflake IDs unique?

A common implementation is a 64-bit structure: 1 sign bit, 41-bit millisecond timestamp, 10-bit machine identifier, and 12-bit intra-millisecond sequence. Uniqueness is effectively split across three variables: time, identity, and count. If any variable goes out of control, duplicates can really happen—not just as a theoretical risk.

• Monotonic clock: On the same worker ID, the time obtained later must not be less than the previous time; otherwise, the generator will reuse an ID range that has already been used.
• Unique identity: Worker IDs and data center IDs are unique across all instances; copy-pasted configuration is a common source.
• Sequence does not overflow: More than 4,096 requests in one millisecond must wait for the next millisecond; the sequence must not wrap around and overwrite.
• Bit width is not squeezed: Business prefixes and sharding bits must not consume worker bits; otherwise, the number of usable instances is silently reduced.

When order numbers collide, should you check worker IDs or the clock first?

Do not guess from ID length and format. Split the ID back into its timestamp segment and worker-bit segment, then compare. If conflicting records are concentrated in one short time window, a clock problem is more likely; if conflicts are scattered across multiple instances, duplicate worker IDs are more likely.

1. Export the conflicting records and check whether the timestamp segment in the IDs is concentrated in the same period.
2. Identify the actual instance in the application logs and check whether the timestamp moved backward or jumped within the same second.
3. Check whether that instance was recently migrated, restarted, time-synced, or manually had its time changed.
4. Check whether the instance's worker ID comes from a configuration center or a fixed value handwritten in a config file, and whether cross-data-center deployments share the same worker-bit range.

Adding a unique index can block dirty data from being written, but the API will return an error directly, and users will see an order placement failure. It is a fallback, not a root-cause fix.

How should clock rollback be handled by severity? Stopping the service is not the only option

The reason to classify it is that rollbacks of different magnitudes have very different handling costs: stopping the service for every case hurts availability, while ignoring every case writes duplicates into primary keys. Classifying by magnitude and adding a recovery action fits common delivery practice in 2026.

• Small rollback (experience range: within tens of milliseconds): spin-wait until after the last ID generation time, then continue; the wait must have an upper limit and must not loop indefinitely.
• Moderate rollback (typical range: tens of milliseconds to several seconds): switch to a reserved backup worker ID, or borrow future timestamps and deduct from the sequence side while emitting metrics and alerts.
• Large rollback (threshold commonly set at 5 to 10 seconds): reject ID generation directly and return an explicit error code; let upstream retry or degrade, and do not generate silently.
• Recovery phase: after confirming the clock is stable, switch back to the original worker ID; keep records of both the switch and the switch-back for later reconciliation.

Delivery experience: worker IDs are handwritten, and scaling day is where things most often go wrong

A fairly typical case involved a tight schedule, a limited budget, and no configuration center. Deployment scaled from two servers to six, and operations copied and pasted worker IDs directly in config files. The test environment had few instances, so nobody noticed. After launch, order numbers occasionally hit unique-key conflicts. A more stable approach is to change worker IDs so they are requested at startup from a registry or a segment table, reject startup if allocation fails, and recycle the ID when an instance goes offline. The cost is an extra allocation table and some recycling logic; integration testing usually takes an extra half day to a day, which is a typical range. But that is far less expensive than later cleaning duplicate orders by time range and repairing related tables. Such changes usually start with rollback and collision detection, then change the allocation method; when Xiyue Company filled this gap during delivery, it followed the same order.

Comparing several ID generation methods

When choosing a primary key scheme, ask three things first: whether trend ordering is needed, whether external dependencies are acceptable, and whether the clock environment is controllable. The four comparisons below are as follows; the numbers are experience ranges, not committed targets.

• Database auto-increment: simple locally and ordered within a single database; sharding requires changing the step size or adding a separate ID generator, cross-shard writes often add one more round trip, and pressure is concentrated in one place.
• UUID v4: generated locally, no external dependency, and does not duplicate; it is unordered and relatively long as a string, so when used as a clustered primary key, inserts are scattered and index maintenance costs rise.
• Segment mode: the database allocates number ranges in batches and the application distributes them in memory; throughput depends on batch size and caching strategy, with an experience range from thousands to tens of thousands per second; the cost is that the segment table itself must remain available.
• Snowflake-style IDs: generated locally, trend-ordered, and small in storage; sensitive to clocks and worker IDs, requiring supporting monitoring and allocation mechanisms, with operations effort concentrated there.

Where Snowflake-style IDs fit—and where they do not

Snowflake-style IDs are suitable for scenarios such as orders, payment transactions, and message identifiers that need trend ordering and do not want to hit the database for every ID. When the number of instances is within dozens and worker IDs can be allocated centrally, implementation risk is relatively controllable.

• Suitable: single or multiple data centers with controlled clocks, relatively high write volume, and a need to approximately reconstruct time order from IDs.
• Not suitable: host clocks that frequently jump by large amounts and cannot be fixed in the short term, instance counts close to worker-bit capacity, or business requirements that IDs precisely express absolute time.
• Not necessary: for systems with a few thousand orders per day and a single database and table that have not reached a bottleneck, auto-increment primary keys or segment mode are usually enough; do not introduce ID-generation complexity yet.

Common questions

If Snowflake IDs are duplicating, can restarting the service buy some time?

Restarting only makes the process read the time again. If the clock is still rolled back or worker IDs still conflict, duplicates will continue after restart. First locate the cause of the collision or rollback.

The worker field has only 10 bits, and the number of instances exceeds capacity—what should we do?

Split the worker bits into data center bits plus instance bits, or switch to segment mode and allocate IDs by business line; when the bit width is exceeded, do not force it by reusing worker IDs.

The time in the container is always a few seconds behind the host—is it because the time zone is not configured correctly?

The time zone only affects display and does not change the timestamp. A difference of a few seconds is usually host clock drift or an unsynchronized time source; check the host side first.

What should be done with duplicate order numbers that have already been generated?

First freeze ID generation and fix the root cause, then export conflicting records by time range for manual review; it is not recommended to change primary keys directly, as that will affect related tables.

If the system already uses Snowflake-style IDs, start with three things: confirm whether worker IDs are allocated centrally, add rollback detection and alerts at the ID generation point, and write the handling methods for different rollback magnitudes into the operations manual. Systems with low daily order volume, few instances, and a simple clock environment do not need to change their primary key scheme for this.