Hacker News Reader

Comment by nchi3 | Hacker News Reader

If you get a "Created" back, it is possible for it to be guaranteed that it'll be created eventually.

What if the object is deleted again? You could still have an inconsistent picture, no? And you could create and delete over and over again, so that a client has an inconsistent picture all the time.

That's a different design issue then - it means lack of synchronization. It is orthogonal to using uuids at a client. In fact, (properly) using uuids are a reasonable way to resolve this.

Not arguing against using UUID. Just exploring that async concept further and the challenges in that. OK 2 separate issues : )

That's what eventual consistency is, isn't it? It's definitely not the easiest thing to design systems around, but at a big enough scale you sometimes don't have a choice.

There's also many ways to "work around it", so that it doesn't seem inconsistent to the user.

I'm definitely not arguing that it's how most systems should be designed though.

I don't think you would ever get a 201 Created in an eventual consistency scenario. You would get a 202 Accepted. Unless the API is lying to the clients.

Fair enough, though what I said remains true for an "Accepted" response.

But Accepted doesn't mean created.

The feedback flow is async from the creation flow.

If you get created through the feedback flow it's created.

Accepted can mean that it will eventually be created though. In the sense that it's validated and guaranteed to be created at a later point ("eventually").

Created can mean different things to different people. Maybe an ecommerce order is created in the sense it's been updated in the inventory database and a record added to some sort of fulfilment system but there's still outstanding data warehouse sync jobs, some order analysis/product recommender job, and some anti fraud jobs (that just need to complete before the order picking in the warehouse begins)

Reply on news.ycombinator.com