0

Working on DDD lately got me thinking about how it preforms on large scale systems.
Watching many tutorials and reading many articles makes it look fun and promising for small projects.

I have three questions for three different categories of DDD.
Lets take the famous example of eCommerce, Say Amazon.

Data Duplication

The core domain would be Products (for this example) and warehouse, sales, orders, etc will all have a copy of product for their bounded context.
I read somewhere that Amazon has ~600 Million products on their site (not including soft deleted ones probably).
Say that all the contexts are using the same structure of Product that cost 12 bytes.
600 Million Products * 12 bytes = 7.2 GB (7,200,000,000 bytes) for each service.
And that's products alone, I'm sure users are duplicated as well and manufacturers and what not.
Does large scale applications simply duplicated data from given Created type of events ?

Domain Events Bombarding

There are more than 1.6 Million packages shipped each day.
That only makes you wonder how's Amazon handling Eventual Consistency with non-stop events coming from every direction.
Assuming that they use Outbox and Inbox like patterns, how do they manage to handle all events on time and not "collect event handling debt" ?

Transactional Overhead

Basically what the titles says, how do they avoid transactional over head ? For example by consuming pending events, handling orders or any transactional behaviors.

I'm sure that the answer can be more storage, more cores, more load balancer and more physical solutions/server solutions, I sure there are technological and architectural solutions for that and I really do wonder what are they that I don't see in small projects using DDD.

Improve this question
8
  • 1
    The question as currently posted is essentially boiling down to "wow, Amazon is big. How do they do it?" which is significantly too vague to be an answerable question. Commented Sep 22, 2023 at 3:45
  • You're talking about systems the size of Amazon and stumbling over 7ish GB. Purely in reporting on customer purchasing data, Amazon collects about 1 exabyte of data (link). That's 1,000,000,000GB (not bytes, gigabytes!). To put that number in perspective, that is like comparing the diameter of Earth to the diameter of a grain of sand (not a figure of speech, I did some actual math here, it's within an order of magnitude). 7GB doesn't even register on their radar. Commented Sep 22, 2023 at 3:49
  • Alternate comparison: 7GB compared to 1 exabyte is the same as comparing 2 years to the time that has passed since the big bang. It is mindbogglingly disparate. Commented Sep 22, 2023 at 3:54
  • @Flater It seems that I explained my self wrongly. "wow, Amazon is big. How do they do it?" is not what I meant, what i meant was that working with DDD for small projects make it look easy, but in my head DDD doesn't scale well in terms of hundred of million of events, or as you say exabytes of duplicate data, another form of my question could be is there a difference from small DDD to enterprise DDD (in terms I mentioned above ) ? Commented Sep 22, 2023 at 8:24
  • 1
    @Br4infreze there's probably a few false assumptions in your question that make it hard to answer. DDD does not imply microservices (some Amazon divisions actually dumped them - thenewstack.io/…). Microservices don't imply eventual consistency, event-driven or a share-nothing communication scheme between services. Some of the concerns you mention are valid, others negligible for a business the size of Amazon. All are variables to be put in balance with a series of benefits and subject to tradeoffs. Commented Sep 29, 2023 at 9:24

1 Answer 1

Reset to default
4

DDD is a broad field. One of the topics is Bounded Contexts which tells us that instead of trying to model the entire enterprise in a giant unified model, we're better of creating linguistic boundaries around separate parts of the enterprise.

When working with products in the context of shipping, we care about which building and which shelf they are located. Working with the same product in the context of the catalog has very different needs, such as photos and pricing information.

DDD does not tell us exactly how we deal with those boundaries, that depends on many factors. For example when we have multiple development teams, working on the same monolithic application introduces some challenges, so we often choose a microservice architecture. When we do so, it makes sense for the microservices to align with the DDD Bounded Contexts.

One of the consequences of a microservice architecture is that there is indeed some data duplication. In the previous example, in both contexts we have the concept of a Product, but not all the details of a product are needed in both contexts. Some basic information to identify a product are probably duplicated, but the catalog doesn't need to know the exact shelf and for shipping we probably don't need to know the price.

The scale of the application and the additional complexity that comes with handling exabytes of data and who knows how many events, is orthogonal to the problems that are solved with DDD.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.