MySQL MEMORY Engine vs NoSQL in-memory

I have a WebService that runs a hybrid functionality of Secure WebSockets and HTTPS REST API. Both functionalities translate the calls to the same under-the-hood generic calls, wherein the WebService automatically serves the needed response. So for an open Secure WebSocket each call will just respond on the open connection and HTTPS REST calls will give a HTTP Response.

WSS Request   ===== |
                    >>> Auth >>> ACL >> HMAC/Crypto (optional) >>> Request processing..
HTTPS Request ===== |

The request gets translated to be generic:

• WSS would be something like: wss://user:pass@https://example.com/ws/ with jSON request entry /users/{id}


• HTTPS REST would be something like: http://ift.tt/1xP2Ntl}

From this point there's a generic jSON that is always the same, no matter if the request was done over WSS or HTTPS.

So let's say from these similar calls..:

• http://ift.tt/1zwqLyK


• wss://example.com/ws/ (with pure JSON instead of URL segments and params)

..I get this final translated request jSON object:

[
    {
        "request": "users",
        "segments": {
            "id": 3892,
        },
        "params": {
            "exclude-fields": [
                "lastname",
                "date-of-birth"
            ],
        },
    },
]

I thought of a caching DB/Table something like this:

+ =============== + ====================== + ========================
| Request Object  | Cache timestamp (UTC)  | Cached Response Object |
+ =============== + ====================== + ========================
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
| {1:1 JSON obj.} | 2015-02-06 10:24       | {JSON Response object} |
+ =============== + ====================== + ========================

So before I would go query for the result in my MySQL database, I would check for the actual same response in the caching table (MEMORY or NoSQL in-memory).

I know there are problems here. I would need to clean cache-rows every time I do UPDATE or DELETE on the table. I could either hold some ID-range in a separate column so I could pinpoint which cache-rows should be either just deleted or updated (I prefer just delete as the cache would have no use anymore if it's never requested anymore anyway). The same goes for migrations on the source table. So when I ALTER the Users table I will clear all cache, when updating my WebService, but this won't really happen a lot I assume.

Last but not least, there's a big issue here when using stuff like offset and limit as parameters (GET http://ift.tt/1zwqKL7 will likely not be correct when caching, as most UPDATES, DELETES and weird manipulation will make the caching response invalid).

So my final question. Would MySQL MEMORY be suitable for this or will NoSQL in-memory (BoltDB maybe? As I'm using Golang) be less resource/cpu intensive?

If any other ways of existing caching would be advised, I would like to hear that :)

Thanks in advance!