5 ms·

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

by nchi3 5y ago

VWWHFSfQ 5y ago
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.
- nchi3 5y ago
  Fair enough, though what I said remains true for an "Accepted" response.
  - NicoJuicy 5y ago
    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.
    - nchi3 5y ago
      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").
- nijave 5y ago
  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)
zelphirkalt 5y ago
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.
- mafuy 5y ago
  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.
  - zelphirkalt 5y ago
    Not arguing against using UUID. Just exploring that async concept further and the challenges in that. OK 2 separate issues : )
- nchi3 5y ago
  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.

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

by nchi3 5y ago

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

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.

nchi3 5y ago
Fair enough, though what I said remains true for an "Accepted" response.
- NicoJuicy 5y ago
  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.
  - nchi3 5y ago
    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").
nijave 5y ago
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)

zelphirkalt 5y ago

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.

mafuy 5y ago
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.
- zelphirkalt 5y ago
  Not arguing against using UUID. Just exploring that async concept further and the challenges in that. OK 2 separate issues : )
nchi3 5y ago
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.