This may be useless, but here is how I would do it. Its kind of related to the "kernel" idea in that I try to discover the heart of the problem a technology sol

This may be useless, but here is how I would do it. Its kind of related to the "kernel" idea in that I try to discover the heart of the problem a technology solves, what the traditional problems are and how a given technology overcomes them. Figure out the problem something solves, try a bunch of simple solutions and see why it fails, ask questions about why things are done a certain way. Example is much more helpful: Q.Whats a database? A. thing to store data Q.why not use a simple text file? A.well there is no way to enforce a schema that way. whats to stop me from adding a line "a,b,c,d" when the schema of the database has only 3 fields? its probably not good for binary data either. ok so well use some specialized format Q.whats an index? why do the use indexes? A.<do research - find they are B-trees that allow you to maintain an order over data> Q. so what happens if multiple people try to write at the same time A. we could global lock the whole table. so only one write is allowed at a time. we could lock on the specific row. with something like CRDTs, order of writes doesn't matter. what if we didnt lock at all? data will be corrupt. this is where consistency models like ACID etc. come in. So my advice is think deeply about the problem being solved, what the difficult sub-problems are and then see what kinds of trade-offs different databases use to deal with them. The more questions you answer, the more questions you will have, but about increasingly detailed slices of the DB/framework/etc. This is learning.