Dedid Laravel Package

Product Decisions This Supports

• Sharding and horizontal scale-out. The decision that auto-increment primary keys stop working once a table is split across databases or regions is the core trigger. A Snowflake-style generator (timestamp + worker/machine id + sequence) lets each node mint its own 64-bit, time-sortable IDs without a central authority or DB round-trip — directly enabling a shard-by-key architecture without a UUID migration.
• Primary key format as a product/API decision. If IDs appear in URLs, exports, or partner APIs, the format is a user-facing contract. This package supports the "short, numeric, sortable" option in the trade-off against UUID/ULID strings, and the choice is expensive to reverse once external systems depend on it.
• Migration off auto-increment. Sequencing the work — add generator, dual-write/backfill, cut over, drop sequences — is a roadmap item with a clear blast radius; the package is only the leaf dependency in that plan.
• Read patterns that depend on ordering. Time-prefixed IDs give you roughly insertion-ordered keys for pagination, audit trails, and event streams, and avoid the B-tree fragmentation and cache churn of random UUIDv4 keys — a capacity/cost decision as much as an engineering one.
• Build vs buy (vs borrow the algorithm). The honest framing: you are not buying a system, you are adopting ~one class plus an operational convention (worker-id assignment, clock-skew policy). That makes "fork and own it" a legitimate third option alongside build and buy.
• Idempotency and correlation keys. The same generator can back request ids, dedupe keys, and outbox/event ids — consolidating a scattered set of ad-hoc uniqid()/microtime() calls into one reviewable mechanism.
• Roadmap gate. Best positioned as a spike/spike-adjacent ticket ahead of any sharding or multi-region-write milestone, not as a standalone feature.

When to Consider This Package

Consider it when all of the following hold:

• You are on PHP and staying there, and you have (or will have) more than one writer — multiple DB nodes, multiple app servers, or multi-region.
• You need 64-bit, monotonically increasing, index-friendly IDs and have explicitly rejected UUIDv4 (random, index-hostile) and long string IDs (storage, URL length).
• You can answer the operational questions the library cannot: how worker/machine IDs are allocated and kept unique (config, Redis, ZooKeeper, k8s ordinal), what happens on clock rollback, and what throughput ceiling per worker is acceptable.
• Someone is willing to own the code: pin a commit, run it against your PHP version, and treat upstream as archived.
• ID enumeration is acceptable from a privacy/security standpoint (sequential IDs leak volume and timing; if not, you need a separate public-id layer).

Look elsewhere when:

• Maintenance is a hard requirement. Last release 2017-12-25, ~22 stars, no visible maintainer activity. That predates PHP 7.2 and certainly PHP 8.x — expect strict-type, deprecation, and integer/pack() portability work, and zero CVE monitoring. If your policy requires a supported dependency, this fails it.
• A maintained alternative covers the same need. UUIDv7 (RFC 9562) and ULID now give time-ordered, non-coordinated IDs with mature, actively maintained libraries and native-ish database support — that removes the main reason to accept an abandoned Snowflake implementation.
• The database can do it. Postgres sequences with per-shard offsets, MySQL auto_increment_increment/offset, or a managed ID service (e.g., cloud Snowflake-style generators) push the problem to infrastructure you already operate and patch.
• Correctness is clock-critical. Multi-region writes with loose NTP, VMs that suspend, or containers with drifting clocks make timestamp-based IDs a footgun unless you own the skew policy.
• You need this yesterday. The integration is a day; the worker-id allocation and clock-skew runbook are the real cost, and this package does not supply them.

PM verdict to carry into planning: adopt the pattern, and treat dekuan/dedid as a reference implementation to fork or replace — not as a supported vendor dependency. Score 0.45 is a fair read: technically on-target, operationally risky.

How to Pitch It (Stakeholders)

To executives (30 seconds): We will eventually need primary keys that can be generated independently on many servers and still sort correctly — that is a prerequisite for sharding and multi-region writes. The established approach is cheap and well understood. The specific PHP library that implements it is small, permissively licensed (Apache-2.0), and unmaintained since 2017, so my recommendation is to adopt the approach using a maintained implementation or a small internal fork, not to take a dependency on this package. Cost is days, not weeks; the schedule risk sits with the sharding milestone, not with this library.

To engineering:

• The algorithm is standard Snowflake-family: timestamp + worker id + per-millisecond sequence, producing sortable 64-bit keys. No service to run, no DB round-trip per insert.
• Treat upstream as read-only. Pin, audit for PHP 8 compatibility, add tests for rollback, sequence exhaustion within a millisecond, and worker-id collisions, then own it.
• Two conventions must be designed before adoption, not after: worker-id allocation and clock-skew behavior. Neither is in the box.
• Alternatives to evaluate in the same spike: UUIDv7 and ULID libraries (actively maintained, sortable, no worker-id problem, but 128-bit/string storage cost), and DB-native sequences with offsets.
• Decide separately whether primary keys are ever exposed publicly; if they are, plan an opaque public id on top.

To security/compliance: sequential IDs are enumerable and reveal creation order and rough volume. Acceptable for internal keys; requires a separate external identifier for customer-facing resources. An unmaintained dependency also has no security-response path — another reason to fork-and-own rather than consume directly.