These are chat archives for RBMHTechnology/eventuate

Dec 2016
Dec 05 2016 08:42
In my opinion, in distributed environments (to get on with network partitions !) you can only use GUID algorithms for ID generation (no sequences et al.). For matching the external data with the generated UIDs you have to ensure causal consistency - so all actors have to join the same event log. You can use in-memory solutions (for example CRDTs: MVRegister or out-of-memory solutions (EventsourcedWriter) with ConditionalRequests. BUT: you have to deal with ConcurrentVersions - so you MUST detect and merge duplicated generated UIDs for the same external data, "Last-Writer-Wins" strategy is not an option for this topic.
Juan Ramón González
Dec 05 2016 11:09
@thomschke My concern about GUIDs is that the clients for my backend are mobile apps and since mobile devices have less resources it may adversely affect the performance of several operations if i use GUIDs instead of simple/smaller incremental int IDs. Anyway what you comment can certainly be an issue. I guess i will have to re-read the CRDT documentation and think more about what i could do, although it is really getting complex...
Marco Ehrentreich
Dec 05 2016 11:30
@jrgonzalezg if you are concerned about the performance impact of creating UUIDs inside the mobile app (is this really a concern with modern smartphones?) you could also consider the application service layer in your backend a client for your domain model and generate UUIDs right there
I'm using a similar design for a web application where we have Spring controllers inside the web layer which talk to application services
the IDs (UUIDs) are generate inside the application services and used inside the domain core and are immediately returned to the calling controllers
with the onion-like architecture and DDD design this works really well for our application
and I'm pretty sure it would work as well if we would have mobile clients instead of web clients
Juan Ramón González
Dec 05 2016 12:21

About the performance... i have been working almost five years in Android development, and i have the opinion that most mobile apps perform poorly (for what could already be done nowadays), but we got used to consider that amount of wait times acceptable :D. It is also true that modern smartphones are fast and can do moderately complex things in a good enough time, but there are also markets with low end smartphones that perform many times slower and have very little memory. In that scenarios some apparently trivial optimizations can mean a lot...

The design you suggest seem interesting to me for content/data generated from user actions received at the application service and i could use it for similar things later on. But the part i am currently focused in where data comes from parsing external systems and the user actions just lead to queries on the processed data does not seem to fit on it too well because the IDs need to be created / queried well before the application layer knows anything about that data.