Decision map — your first bet

The Commandant puts an inventory in front of you — eight tasks Kotomarket handled every day. “Where did each one live? Just make your best guess. Details later.”

QUERY: It's fine to be wrong here. Write down your first version, and we'll check it only at the end of the course. Let's see how many choices you can guess before you even meet the stores themselves.

Eight cards

Click “Run”: show_cards() is the training function for this lesson. It prints eight Kotomarket tasks and six options for where to store them.

Don’t try to guess the store from a single word on the card. “Sessions,” “payments,” or “search” do not give you the answer by themselves. First look at what the program does with this data.

Start with how the program accesses a record. Does it know the exact key and want to quickly get the record tied to it? Or does it need to find records by a condition, by words, or by relationships between objects? These are different tasks, even if the amount of data is the same.

Then look at the rhythm of the work. Some data is read again and again, while other data is constantly changed. Sometimes it is fine to briefly see an old answer, and sometimes you need the newest one right after a change.

The last question is unpleasant but useful: what happens if some of the data disappears? A lost ready-made list can be rebuilt. With orders and payments, that kind of carelessness is already dangerous.

The cards do not tell you everything. Where information is missing, make a reasonable assumption and write down your bet. This is a draft decision, not an exam.

How to make your bet

You have eight tasks and six options in front of you at once. If you try to keep every clue in your head at the same time, the choice quickly turns into guessing. So run every card through the same questions.

First, figure out how the program gets to the data it needs. A task where the exact key is known works differently from a search by words, by a condition, or by relationships between objects.

Then compare reads and changes. A ready-made result that is shown often behaves differently from data that is constantly rewritten.

After that, ask about freshness. If one copy lags a little behind, will the user even notice? For one task, an old answer is acceptable for a short time; for another, it changes the meaning of the action.

Finally, judge the cost of loss. Some data can be retrieved again from the main database or calculated again. Other data must not disappear.

Only after those questions should you look at the size and shape of the records. That way, a word like “documents,” “graph,” or “search” does not replace the task itself.

The most common trap

The inventory has a line that says “cards for 20 products with different attributes.” It is easy to see “different attributes” and immediately choose documents: one card has one set of fields, another has a different set.

A different record shape really can make documents convenient. But that answers only the question of how to arrange the data inside a record. It says nothing about how the program will need to find that data, how often it will change, or how fresh the answer must be.

Suppose a card is usually found by product number and changed once a week. A separate document store may not be needed at all just because the fields differ. The main database can handle that too: PostgreSQL can store JSON directly in a table column, and each product can have its own set of fields inside it.

There is one more useful question: what does the program usually need after opening the card? If it gets the product name, price, and special attributes all at once, it is convenient to read that card in one request. In spirit, this is like a folder with a product form: open the folder and immediately see everything that belongs to that card instead of assembling it piece by piece.

But this clue does not choose a store by itself either. A card may be convenient to read as a whole, while products are searched by the customer’s words. Those two actions have different requirements, so your bet should be based on the specific task in the inventory.

In real work, this kind of choice comes up around PostgreSQL, MongoDB, Redis, Elasticsearch, and Neo4j. It is usually discussed before the systems themselves are configured: first you list how the program accesses the data, and only then decide which store is responsible for what.

QUERY: People trip over “different fields means documents” all the time. Then it turns out the new store added almost nothing, but now it has to be updated, monitored, and fixed in the middle of the night.