Hey folks! Can you help me with a modeling question about 1:1 “sub-resources” in Zanzibar-style schemas? I have a parent object type

project

, and a 1:1 child object type

deploy_key

(plus several other 1:1 children). I need to authorize: PATCH /projects/{projectId}/deploy-key Allowed callers: - the

holder

of that project’s

deploy_key

- the

owner

of the

project

Two modeling options: A) Reuse the same ID for the 1:1 child:

deploy_key:{projectId}

B) Use a distinct child ID and map it from the parent:

project:{projectId}#deploy_key@deploy_key:{deployKeyId}

Are there best practices or gotchas for (A) vs (B)? Is there a recommended option? Thanks!

i think it comes down to whether you think the semantic is going to change in the future

yeah that’s pretty much where i’m landing too if it stays truly 1:1 forever, i agree the day-to-day ops differences aren’t huge. my hesitation is more about the write/invariant surface with option B: once the parent starts accumulating lots of 1:1 children, you end up maintaining a bunch of pointers, and drift becomes easier unless the writer is super disciplined on the parent object. if we think “multiple keys” might happen, option B feels like the safer foundation. however, it comes with a cost. do you usually use explicit parent->child mappings for 1:1 objects?

at my old job i remember us having linkages that could move. i don't remember if they were 1-1 or 1:m but it entailed some bookkeeping where we needed to clean up rels. we made use of kafka for syncing state between the rest of the app and spicedb, and it took us a while to get all of the logic correct and tested, but once we got there it worked pretty well.