4

The point of microservices is to enable independent development and operation of parts of a larger software system. What is your goal in this project, what is the reason you are doing this? A microservice is not a subtree of a data model. It is a closed, feature complete part of the whole, that has (ideally) no request-response dependency to other systems, ...


3

The standard technique for this sort of reporting work is to define the aggregates you need, and then compute them incrementally on a regular basis and store the results. Then, when the time comes to prepare the report, you assemble it (at least, as much as possible) from these stored results. The computation of longer-range aggregates may itself use ...


3

Your structure so far looks reasonable with a few caveats, so don't be too hard on yourself. I wouldn't store any information about the components in the Products table directly if possible, so get rid of the part_list_id col. The product_id will give you the hook to build the component list later. This also means that you could add 'temporary' products to ...


2

It's fair for microservices to access other services for data. I'd look into the saga pattern for ideas how to deal with distributed data in a microservices architecture.


2

Having a separate pre-filtered list isn't that bad of an idea for many use cases and I imagine FB do use something like that for its News Feed. For example, product recommendations on a web shop. You don't have time to do fancy AI every-time a user browses or adds an item to a basket. But you can premake lists of items that are similar to each other and tag ...


2

You are started off in the right direction with having separate tables for posts, images and videos, but your data model has gone awry in two ways: Add a "post_text" column to your "posts" table and make it nullable instead of a separate "text_post" table. If this is optional (which it is for video and image posts) then the database can reflect that with a ...


2

Yes, this is a decent way to handle this problem on the back-end side: you handle each class as a distinct table (Post, TextPost, ImagePost and VideoPost), you use composition to model the association between a Post and its specialistion XxxPost, with the Xxx_Post_id The only problem is that if you add more post types, you will have to add more ids in ...


2

Normally, for full historical tracking, you don't need the current status in a different table. Instead, add two timestamps to your table which represent the start of the given time slice, and the end of the given timeslice. For an update, just set the end timestamp and insert a new row. Something like this: userid | status | validFrom | ...


2

You should store the replies as its own document because you can get scaling problems if storing with the review. This is an important part of DDD where it is called a consistency boundary. I assume you want multiple users to be able to post a reply independently of each other. If you are storing them together you can risk some replies fail just because ...


1

If you have gone with a Heterogenous DB setup, you have only a couple of options. 1. Handle aggregations in the application: I wouldn't mind doing this if the data is of small size or the response is small (for instance, deriving some data for a single logged in user from 2 sources) and you don't have to do multiple joins in the critical path of your ...


1

With your current model, you have to change a lot of stuff whenever you want to add a new post type: Add a new _id column to the post table Create a new table to store content for the new post type Add a new field to your response structure That doesn't seem very scalable to me. Instead, I would just store a type column in the post table indicating the ...


1

I would model this with a state change request table. It would refer to the object and the kind of change (publish, delete, replace content). If the request is approved, the state change is executed. Special consideration would be needed when multiple state change requests are in flight.


1

Generally you should design your data model to match the real-world requirements and not commit premature optimization. Hundreds of thousands of rows are not a challenge for a modern database engine. Give some thought to what your partition key could be. Partitioning would keep your data logically in one set while allowing the database to optimize for ...


1

While trying to improve my applications' simple searches to bigrams and trigrams from unigrams, essentially, I saw your question. If one of requirements is ability to query a distributed file system or database, then this might be interesting for you too: the paper Pibiri and Venturini 2018 "Handling Massive N-Gram Datasets Efficiently" outlines an ...


Only top voted, non community-wiki answers of a minimum length are eligible