docs: tweaks

README.md

@@ -1,8 +1,6 @@
 <div align="center">
-  <img src="https://github.com/microlinkhq/cdn/raw/master/dist/logo/banner.png#gh-light-mode-only" alt="microlink logo">
-  <img src="https://github.com/microlinkhq/cdn/raw/master/dist/logo/banner-dark.png#gh-dark-mode-only" alt="microlink logo">
-  <br>
-  <br>
+  <img src="https://github.com/microlinkhq/openkey/raw/master/design/banner.jpg#gh-light-mode-only" alt="microlink logo">
+  <img src="https://github.com/microlinkhq/openkey/raw/master/design/banner.jpg#gh-dark-mode-only" alt="microlink logo">
 </div>
 
 ![Last version](https://img.shields.io/github/tag/microlinkhq/openkey.svg?style=flat-square)
@@ -11,6 +9,19 @@
 
 > an AWS Gateway replacement for usage plans and keys for your HTTP API endpoint
 
+## Concepts
+
+<div align="center">
+  <img src="https://github.com/microlinkhq/openkey/raw/master/design/concepts.jpg#gh-light-mode-only" alt="microlink logo">
+  <img src="https://github.com/microlinkhq/openkey/raw/master/design/concepts.jpg#gh-dark-mode-only" alt="microlink logo">
+</div>
+
+**openkey** orbits around three concepts:
+
+- **Plans**: Represents the quota, rate limit, and throttle information specified as a plan.
+- **Keys**: Represents the credentials used during the authentication step and which plan is associated.
+- **Usage**: Keep track of how much plan is available and consumed with the associated key.
+
 ## FAQ
 
 ### Why?
@@ -21,6 +32,10 @@ Until **openkey**, we use AWS Gateway feature for keys and plans for years. Alth
 
 No, and we are not aspiring for it. We used to use a very specific feature present in the AWS Gateway service, and **openkey** is a replacement for that features, that's all. AWS Gateway can still do a lot of more things that this library.
 
+### Why not TypeScript?
+
+This library is intended to be used millions of times every day. We wanted to have granular control as much as possible, and adding a TypeScript transpilation layer isn't ideal from a performance and maintenance perspective.
+
 ### Why Redis?
 
 We needed a backend layer fast for frequent writes, cheap at scale and mature enough for preventing vendor-lock in. We considered other alternatives such as SQLite, but according with this requeriments Redis is the no brain selection.