3 ms·

I like this architecture but I worry that in sufficiently complex systems it can lead to some significant complexity if there are entities within the database t

by zmmmmm 7y ago

I like this architecture but I worry that in sufficiently complex systems it can lead to some significant complexity if there are entities within the database that have a lot of contention around them. For example, it may end up translating to deadlocks etc. when two services that are naive to each other start locking tables in interleaved sequences of interactions. It still seems wise even if you follow this pattern to segment areas of the database to management of particular services or consumers and then have those present APIs or message passing interfaces to each other. Which leads you half way back to SOA or microservices.

Eyas 7y ago
Yeah, totally. The way I've seen this work is that a single service will "own" a record, so you never are running into a multi-writer situation for a given record. While this seems closer to SOA, the key difference here is that single Type or Table can still have multiple produces (of non-overlapping records). In a trading system, you'd have producers of RFQs from makretplace A, B, C, etc. but for each single row in that table, the same service "owns" it. So you still get the benefits of not caring about the DAG/callgraph or knowing about the individual service that calls you. Locking might be hard if you're doing some transactional change. Those become harder to do. But the half good news is that shifting to an "Event-based" programming mindset might mean you run into less of these. But yeah, there's a whole new set of drawbacks.
- nine_k 7y ago
  But what's the point to keep them in the same table then? Won't having several independent (and maybe physically remote) tables, one per service, solve the problem better? You can still `union all` them for analytical purposes.
  - Eyas 7y ago
    Same schema, and the service doing the query doesn't need to worry about which tables to union. (Problem with union all is that it reintroduces addressability and a form of direct component interaction) But sure, you can probably implement that with views etc. also.

by zmmmmm 7y ago

Eyas 7y ago

Yeah, totally. The way I've seen this work is that a single service will "own" a record, so you never are running into a multi-writer situation for a given record. While this seems closer to SOA, the key difference here is that single Type or Table can still have multiple produces (of non-overlapping records). In a trading system, you'd have producers of RFQs from makretplace A, B, C, etc. but for each single row in that table, the same service "owns" it. So you still get the benefits of not caring about the DAG/callgraph or knowing about the individual service that calls you. Locking might be hard if you're doing some transactional change. Those become harder to do. But the half good news is that shifting to an "Event-based" programming mindset might mean you run into less of these. But yeah, there's a whole new set of drawbacks.

nine_k 7y ago
But what's the point to keep them in the same table then? Won't having several independent (and maybe physically remote) tables, one per service, solve the problem better? You can still `union all` them for analytical purposes.
- Eyas 7y ago
  Same schema, and the service doing the query doesn't need to worry about which tables to union. (Problem with union all is that it reintroduces addressability and a form of direct component interaction) But sure, you can probably implement that with views etc. also.