4 ms·

No, it doesn’t work for that use-case. It would all need to happen within a single service in a single invocation. To enable transactions across network bounda

No, it doesn’t work for that use-case. It would all need to happen within a single service in a single invocation. To enable transactions across network boundaries, you need to enable the transactional safety at the application/API level. And, for the record, one service per table is a terrible idea. It would have none of the benefits of a service-oriented architecture, while adding all the complexity and caveats of a distributed architecture.

ChicagoDave 9y ago
Except I've implemented it that way in highly visible, high traffic internal web applications that were lauded as some of the most successful transitions in company history in a very large corporation. So your argument is really legacy opinion and not relevant to micro-service architectures.
- BillinghamJ 9y ago
  None of the things you've just said make any difference to the fact that it doesn't make sense and is a terrible idea. I fail to see in what way my statements are "legacy" or not relevant to micro-services. My company (Cuvva, insurance in the UK) runs a "micro" service architecture and deals with these problems every day. It is not possible to use DB-level locking/transactions across network boundaries. It's just as simple as that. It's not an opinion - it's a fact.
  - thawkins 9y ago
    Not even using 'XA'?
  - ChicagoDave 9y ago
    I wasn't responding to the distributed transaction argument, though nothing in the MongoDB blog says it won't support it. I was specifically responding to "one table one service" which is the foundation of domain driven micro service architecture. To have a single domain silo'd and tested within its own boundaries. Whether you're firing events between services or just calling other services is a design decision, but the encapsulation of a specific domain is the point and the primary benefit. I have no idea what you're doing, but this is what I worked on: https://www.accenture.com/us-en/success-performance-management-achievement https://www.accenture.com/us-en/success-performance-manageme... Which proves that silo'd micro-services are cost-effective and produce real world results in a complex environment. Feel free to knock more points off my karma. :)
    - Fins 9y ago
      Just because something can be done, including the fashionable microservices "architecture", it does not mean that it should be done, or that it is a good idea.
      - ChicagoDave 9y ago
        Application architecture is inherently malleable, yes. But when properly implemented, micro service architecture is actually a great idea. I can’t help if your experience has not been the same as mine.
        Fins 9y ago
        Certainly, one can architect anything, use NoSQL for critical data storage, or use Kafka for synchronizing two SQL databases with the same schema and living on the same netowrk(an actual proposal from a fan of microservices, btw). But whether it should be done is another question, and I have yet to see a single example of microservices being a good idea. Not "it works" -- obviously, you can get it to work, but being better than alternatives. Come to think of it, Mongo is the same...
        ChicagoDave 9y ago
        The Accenture link I posted is a living example of a highly successful micro-services architecture in a critical internal application in a large corporation. What more do you want?

ChicagoDave 9y ago

Except I've implemented it that way in highly visible, high traffic internal web applications that were lauded as some of the most successful transitions in company history in a very large corporation. So your argument is really legacy opinion and not relevant to micro-service architectures.

BillinghamJ 9y ago
None of the things you've just said make any difference to the fact that it doesn't make sense and is a terrible idea. I fail to see in what way my statements are "legacy" or not relevant to micro-services. My company (Cuvva, insurance in the UK) runs a "micro" service architecture and deals with these problems every day. It is not possible to use DB-level locking/transactions across network boundaries. It's just as simple as that. It's not an opinion - it's a fact.
- thawkins 9y ago
  Not even using 'XA'?
- ChicagoDave 9y ago
  I wasn't responding to the distributed transaction argument, though nothing in the MongoDB blog says it won't support it. I was specifically responding to "one table one service" which is the foundation of domain driven micro service architecture. To have a single domain silo'd and tested within its own boundaries. Whether you're firing events between services or just calling other services is a design decision, but the encapsulation of a specific domain is the point and the primary benefit. I have no idea what you're doing, but this is what I worked on: https://www.accenture.com/us-en/success-performance-management-achievement https://www.accenture.com/us-en/success-performance-manageme... Which proves that silo'd micro-services are cost-effective and produce real world results in a complex environment. Feel free to knock more points off my karma. :)
  - Fins 9y ago
    Just because something can be done, including the fashionable microservices "architecture", it does not mean that it should be done, or that it is a good idea.
    - ChicagoDave 9y ago
      Application architecture is inherently malleable, yes. But when properly implemented, micro service architecture is actually a great idea. I can’t help if your experience has not been the same as mine.
      - Fins 9y ago
        Certainly, one can architect anything, use NoSQL for critical data storage, or use Kafka for synchronizing two SQL databases with the same schema and living on the same netowrk(an actual proposal from a fan of microservices, btw). But whether it should be done is another question, and I have yet to see a single example of microservices being a good idea. Not "it works" -- obviously, you can get it to work, but being better than alternatives. Come to think of it, Mongo is the same...
        ChicagoDave 9y ago
        The Accenture link I posted is a living example of a highly successful micro-services architecture in a critical internal application in a large corporation. What more do you want?