Jump to a problem, path or page
Jump to a problem, path or page
Updates as you edit. Run the review to record it; passing every check completes the problem.
Not yet passed: Client responsibility
Add Client and define its responsibility.
Not yet passed: API service responsibility
Add API service and define its responsibility.
Not yet passed: Database responsibility
Add Database and define its responsibility.
Not yet passed: Worker registry responsibility
Add Worker registry and define its responsibility.
Not yet passed: ID generator responsibility
Add ID generator and define its responsibility.
Not yet passed: Clock responsibility
Add Clock and define its responsibility.
Not yet passed: Client → API service
A directed path must connect Client to API service. Arrows represent requests, dependencies, or event flow.
Not yet passed: API service → ID generator
A directed path must connect API service to ID generator. Arrows represent requests, dependencies, or event flow.
Not yet passed: API service → Database
A directed path must connect API service to Database. Arrows represent requests, dependencies, or event flow.
Not yet passed: ID generator → Worker registry
A directed path must connect ID generator to Worker registry. Arrows represent requests, dependencies, or event flow.
Not yet passed: ID generator → Clock
A directed path must connect ID generator to Clock. Arrows represent requests, dependencies, or event flow.
Not yet passed: What should happen when the clock goes backward?
Not yet passed: Does a time-sortable ID establish global event order?
Not yet passed: What happens on sequence exhaustion within one tick?
Not yet passed: API and data model notes
Write at least 80 characters describing concrete operations, inputs, outputs, state and errors. This check measures completeness, not semantic correctness.
Not yet passed: Trade-offs and failure cases
Write at least 80 characters about alternatives, failure handling and edge cases. Review the reasoning yourself using the reference discussion.
Rule-based educational feedback. Notes are checked by length only; topology checks confirm directed reachability. These checks do not validate semantics, latency, reliability or every valid design.
Use explicit timestamp/worker/sequence fields with serialized per-worker generation and conservative issuance bounds. Uniqueness depends on exclusive worker identity ownership and safe persisted restart state. Choose an epoch and millisecond ticks. A 41/10/12 layout offers 1024 worker slots and 4096 IDs per worker per tick within the timestamp lifetime. Return IDs as decimal strings to clients that cannot represent 64-bit integers exactly. Provision worker IDs exclusively through a registry. This design does not automatically reassign an uncertain worker slot: drain or otherwise prevent the old issuer from running before reuse. Registry leases alone are insufficient to fence returned IDs. Persist a reserved timestamp high-water bound before issuing inside that window. After restart, refuse issuance until actual safe time is beyond the previous reserved window; reserve another window durably. A registry/store failure blocks new reservation, not permission to reuse old IDs. Under a per-worker lock, clamp no timestamp backward: wait with a deadline or fail on regression. Reset sequence only on a new tick; on exhaustion wait for a safe tick. Reject timestamps outside the bit lifetime.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.