This may be useless, but here is how I would do it. Its kind of related to the &quot;kernel&quot; 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.<p>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.<p>Example is much more helpful:<p>Q.Whats a database?<p>A. thing to store data<p>Q.why not use a simple text file?<p>A.well there is no way to enforce a schema that way. whats to stop me from adding a line &quot;a,b,c,d&quot; when the schema of the database has only 3 fields?<p>its probably not good for binary data either.<p>ok so well use some specialized format<p>Q.whats an index? why do the use indexes?<p>A.&lt;do research - find they are B-trees that allow you to maintain an order over data&gt;<p>Q. so what happens if multiple people try to write at the same time<p>A. we could global lock the whole table. so only one write is allowed at a time.<p>we could lock on the specific row.<p>with something like CRDTs, order of writes doesn&#x27;t matter.<p>what if we didnt lock at all?<p>data will be corrupt.  this is where consistency models like ACID etc. come in.<p>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.<p>The more questions you answer, the more questions you will have, but about increasingly detailed slices of the DB&#x2F;framework&#x2F;etc. This is learning.