Forem: Mustafa Bingül

How I Rebuilt a Three-Layer Cache System in Java — Redis, L1, and MongoDB Done Right

Mustafa Bingül — Sat, 25 Apr 2026 19:03:03 +0000

I've been working on Nexus, a backend infrastructure project, and recently hit a point where the data synchronization layer needed a serious rethink. What looked like a working cache system turned out to have a broken hierarchy, silent data loss paths, race conditions, and a latent deadlock waiting to happen.

This post walks through every problem I found in the original code and exactly how I fixed each one. Code comparisons included throughout.

The Architecture: What We're Building

The system manages data across three layers:

┌─────────────────────────────────┐
│        Redis Cache (MASTER)     │  ← single source of truth
└────────────┬──────────┬─────────┘
             │          │
       pull 10s      flush 15s
             │          │
┌────────────▼──┐  ┌────▼──────────────┐
│  L1 Cache     │  │     MongoDB        │
│  (in-memory)  │  │  (persistent DB)   │
└───────────────┘  └────────────────────┘

The rules are simple:

Redis is always master. No other layer can override it.
L1 is an in-memory mirror of Redis. It reads from Redis, never the other way around.
MongoDB is the persistent backup. Redis writes to it — not the other way around.

Three scheduled tasks keep everything in sync:

Task	Interval	Job
L1 Sync	10s	Pull Redis → update L1 if changed
Auto Flush	15s	Push dirty keys from Redis → MongoDB
Reconciliation	3 min	Compare Redis ↔ MongoDB, Redis wins

Now let's look at what was actually wrong with the original implementation.

Problem 1: The Hierarchy Was Backwards

This was the most fundamental issue. The reconciliation task was supposed to enforce Redis as master — but it was doing the opposite.

The original code

private void startReconciliationTask() {
    redisManager.processTask(() -> {
        idToDataList.forEach((keyTag, model) -> {
            if (dirtyKeys.contains(keyTag)) return;

            NexusApplication.getApplication().getMongoManager()
                .getValue(model.getAddon(), model.getSpecificDbKey())
                .thenAccept(dbJson -> {
                    if (dbJson == null) return;
                    try {
                        String cleanDbJson = model.getAddon().modelInitComp(dbJson);
                        if (!cleanDbJson.equals(model.getValueJson())) {
                            model.setValueJson(cleanDbJson);          // ← overwriting L1 with Mongo
                            redisManager.setData(keyTag, cleanDbJson); // ← overwriting Redis with Mongo!
                        }
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                });
        });
    });
}

When MongoDB had a different value than Redis, it was writing MongoDB's value into Redis. MongoDB was effectively acting as master. The entire priority chain was inverted.

The fix

private void startReconciliationTask() {
    RedisManager rm = NexusApplication.getApplication().getRedisManager();

    rm.processTask(() -> {
        // ...
        // Get the master value from Redis first
        String redisJson = rm.getData(key).orElseGet(model::getValueJson);

        NexusApplication.getApplication().getMongoManager()
            .getValue(model.getAddon(), model.getSpecificDbKey())
            .thenAccept(dbJson -> {
                // ...
                String cleanDbJson = model.getAddon().modelInitComp(dbJson);

                // Redis wins. If Mongo is different, update Mongo — not Redis.
                if (!cleanDbJson.equals(redisJson)) {
                    NexusApplication.getApplication().getMongoManager()
                        .setValue(model.getAddon(), model.getSpecificDbKey(), redisJson);
                    model.setValueJson(redisJson); // L1 follows Redis
                }
            });
    });
}

Redis is fetched first and treated as the ground truth. When there's a mismatch, MongoDB gets corrected — never Redis.

Problem 2: Silent Data Loss on Flush Failure

The auto flush task was removing the dirty flag before confirming the MongoDB write succeeded.

The original code

private void startAutoSyncTask() {
    List<String> keysToSync = new ArrayList<>(dirtyKeys);
    dirtyKeys.removeAll(keysToSync); // ← removed before writing to Mongo

    redisManager.processTask(() -> {
        for (String key : keysToSync) {
            DataModel model = idToDataList.get(key);
            if (model != null) {
                NexusApplication.getApplication().getMongoManager()
                    .setValue(model.getAddon(), model.getSpecificDbKey(), model.getValueJson());
                // if this fails, the key is already gone from dirtyKeys
                // it will never be retried
            }
        }
    });
}

If the MongoDB write threw an exception or the future completed exceptionally, the dirty flag was already removed. The entry would never be retried. Data was silently lost.

The fix

private void startAutoFlushTask() {
    List<String> keysToFlush = new ArrayList<>(dirtyKeys); // snapshot — don't removeAll yet

    rm.processTask(() -> {
        for (String key : keysToFlush) {
            DataModel model = keyToModel.get(key);
            if (model == null) {
                dirtyKeys.remove(key);
                continue;
            }

            String jsonToWrite = rm.getData(key).orElseGet(model::getValueJson);

            try {
                NexusApplication.getApplication().getMongoManager()
                    .setValue(model.getAddon(), model.getSpecificDbKey(), jsonToWrite)
                    .get(); // block until Mongo confirms the write

                dirtyKeys.remove(key); // only remove AFTER confirmed success

            } catch (Exception e) {
                // leave the key dirty — it will be retried on the next flush
                LOGGER.log(Level.SEVERE, "[AutoFlush] Write failed, will retry: " + key, e);
            }
        }
    });
}

Two changes here: the dirty flag snapshot is taken but not immediately cleared, and dirtyKeys.remove(key) only runs after .get() confirms the write succeeded. If anything goes wrong, the key stays dirty and gets retried 15 seconds later.

Problem 3: TOCTOU Race Condition in removeModel()

TOCTOU stands for Time-of-Check to Time-of-Use. The original removeModel() checked if a key existed before removing it — but another thread could delete it between those two operations.

The original code

public void removeModel(String key) {
    if (idToDataList.containsKey(key)) {  // Thread A checks: key exists
        // --- Thread B deletes the key here ---
        dirtyKeys.remove(key);
        idToDataList.remove(key);          // Thread A removes: but key is already gone
        NexusApplication.getApplication().getRedisManager().deleteData(key);
    }
}

In a concurrent environment, this is not safe. The containsKey check and remove call are two separate operations with no atomicity guarantee between them.

The fix

public void removeModel(String key) {
    DataModel removed = keyToModel.remove(key); // atomic: check + remove in one step
    if (removed == null) return; // wasn't there — nothing to do

    idToKey.remove(removed.getId());
    dirtyKeys.remove(key);
    NexusApplication.getApplication().getRedisManager().deleteData(key);
}

ConcurrentHashMap.remove() is atomic. Its return value tells you whether anything was actually removed. One operation, no race.

Problem 4: Deadlock Risk in Reconciliation

The original reconciliation task was dispatching a new processTask from inside an already-running processTask.

The original code

redisManager.processTask(() -> {
    idToDataList.forEach((keyTag, model) -> {
        // ...
        NexusApplication.getApplication().getMongoManager().getValue(...)
            .thenAccept(dbJson -> {
                // ...
                redisManager.processTask(() ->   // ← new task dispatched from inside a running task
                    NexusApplication.getApplication().getMongoManager()
                        .setValue(...));
            });
    });
});

If processTask uses a single-threaded executor (which is common for Redis clients to ensure command ordering), submitting a new task from inside a running task means the inner task can never start — the outer task is blocking the only available thread. That's a deadlock.

The fix

Everything runs in a single processTask context. The MongoDB writes inside thenAccept are plain async calls — no nested processTask.

rm.processTask(() -> {
    for (String key : keys) {
        // ...
        CompletableFuture<?> future = NexusApplication.getApplication()
            .getMongoManager()
            .getValue(...)
            .thenAccept(dbJson -> {
                // ...
                // direct Mongo write — no nested processTask
                NexusApplication.getApplication().getMongoManager()
                    .setValue(...);
            });

        batch.add(future);
        if (batch.size() >= RECONCILE_BATCH_SIZE) {
            waitForBatch(batch);
            batch.clear();
        }
    }
});

All reconciliation work happens inside one task. No task dispatches another task.

Problem 5: MongoDB Request Storm on Large Datasets

The original reconciliation fired a MongoDB query for every single entry simultaneously — no throttling, no batching.

On 1000+ entries, that means 1000+ concurrent MongoDB reads, followed immediately by potentially 1000+ writes. This can exhaust connection pools, spike latency, and cause cascading failures under load.

The fix: batch processing

private static final int RECONCILE_BATCH_SIZE = 50;

// inside startReconciliationTask:
List<CompletableFuture<?>> batch = new ArrayList<>(RECONCILE_BATCH_SIZE);

for (String key : keys) {
    if (dirtyKeys.contains(key)) continue;
    // ...

    CompletableFuture<?> future = mongoManager.getValue(...).thenAccept(...);
    batch.add(future);

    if (batch.size() >= RECONCILE_BATCH_SIZE) {
        waitForBatch(batch); // wait for all 50 to complete
        batch.clear();       // then start the next 50
    }
}

if (!batch.isEmpty()) waitForBatch(batch);

private void waitForBatch(List<CompletableFuture<?>> batch) {
    try {
        CompletableFuture.allOf(batch.toArray(new CompletableFuture[0])).get();
    } catch (Exception e) {
        LOGGER.log(Level.WARNING, "[Reconciliation] Batch wait error", e);
    }
}

At most 50 concurrent MongoDB requests are in flight at any time. The next batch only starts when the current one is done. This is easy to tune — bump RECONCILE_BATCH_SIZE if your MongoDB can handle more concurrency, lower it under constrained environments.

Problem 6: Redis Evict/TTL Was Silently Ignored

Redis can evict keys under memory pressure or when a TTL expires. The original L1 Sync did nothing when it detected a missing key.

The original code

redisManager.getData(key).ifPresent(redisJson -> {
    if (!redisJson.equals(model.getValueJson())) {
        model.setValueJson(redisJson);
    }
    // if getData() returns empty — we just skip it silently
    // L1 is now out of sync with an evicted Redis key
});

When a key was evicted from Redis, L1 kept its stale value indefinitely. The next flush would try to read from Redis, get nothing, fall back to L1's stale data, and write that to MongoDB — potentially losing the newer value that was in Redis before eviction.

The fix

Optional<String> redisOpt = rm.getData(key);

if (redisOpt.isPresent()) {
    String redisJson = redisOpt.get();
    if (!redisJson.equals(model.getValueJson())) {
        model.setValueJson(redisJson); // L1 follows Redis
    }
} else {
    // Key was evicted from Redis — restore it from L1 and re-dirty
    LOGGER.warning("[L1Sync] Redis key missing, restoring: " + key);
    rm.setData(key, model.getValueJson()); // restore Redis from L1
    dirtyKeys.add(key);                    // trigger a Mongo re-write too
}

When Redis doesn't have a key, L1's value is pushed back into Redis (restoring the master) and the key is marked dirty so the flush task re-persists it to MongoDB.

Problem 7: addModelFix() Left Redis Empty

This method was supposed to handle externally-provided data, but it only wrote to L1 — leaving Redis without the key.

The original code

public void addModelFix(String key, DataModel model) {
    idToDataList.put(key, model); // writes to L1 only
    dirtyKeys.add(key);
    // Redis has no entry for this key
    // Next L1 Sync will detect the missing Redis key, restore it from L1,
    // and re-dirty it — unnecessary extra cycle
}

The fix

public void addModelFix(String key, DataModel model) {
    writeToL1AndRedis(key, model); // writes both L1 and Redis together
    dirtyKeys.add(key);
}

All write paths now go through the same internal method, which guarantees both layers are always updated together.

Problem 8: O(n) ID Lookup

The getDataModelFromId() method streamed through the entire map on every call.

The original code

public Optional<DataModel> getDataModelFromId(String id) {
    return idToDataList.values().stream()
        .filter(dm -> dm.getId().equals(id))
        .findAny(); // O(n) — scans the whole map
}

On 1000 entries this is 1000 comparisons per lookup. If this method is called frequently (e.g., per player action in a game server), it compounds fast.

The fix: reverse index

A second ConcurrentHashMap keeps a id → key mapping updated alongside the main map.

// new field
private final ConcurrentHashMap<String, String> idToKey;

// updated on every write
private void writeToL1AndRedis(String key, DataModel model) {
    keyToModel.put(key, model);
    idToKey.put(model.getId(), key); // maintain reverse index
    NexusApplication.getApplication().getRedisManager().setData(key, model.getValueJson());
}

// and on remove
public void removeModel(String key) {
    DataModel removed = keyToModel.remove(key);
    if (removed == null) return;
    idToKey.remove(removed.getId()); // keep reverse index clean
    // ...
}

// lookup is now O(1)
public Optional<DataModel> getDataModelFromId(String id) {
    String key = idToKey.get(id);
    if (key == null) return Optional.empty();
    return Optional.ofNullable(keyToModel.get(key));
}

Two map lookups instead of a full scan. The memory cost is minimal — just a second map of strings.

The Final Picture

Here's a summary of every change made:

#	Problem	Impact	Fix
1	Hierarchy inverted — Mongo was overriding Redis	Wrong data served	Redis fetched first; Mongo updated to match Redis
2	Dirty flag removed before Mongo write confirmed	Silent data loss	`dirtyKeys.remove()` called only after `.get()` succeeds
3	TOCTOU race in `removeModel()`	Potential NPE / double-delete	Single atomic `remove()` with return value check
4	Nested `processTask` in reconciliation	Deadlock on single-thread executor	All work in one task context, no inner dispatch
5	All entries queried simultaneously in reconciliation	MongoDB connection storm	Batch processing (50 at a time) with `CompletableFuture.allOf()`
6	Redis evict/TTL silently ignored in L1 Sync	Stale L1 data, wrong Mongo writes	Restore Redis from L1, mark dirty
7	`addModelFix()` skipped Redis	Redis missing key, extra sync cycle	Unified `writeToL1AndRedis()` for all write paths
8	`getDataModelFromId()` was O(n)	CPU pressure on 1000+ entries	`id → key` reverse index for O(1) lookup

Takeaway

The original code wasn't obviously broken — it ran, it synced, it mostly worked. The bugs were in the edge cases: what happens when Mongo is unavailable for one cycle, when Redis evicts a key under pressure, when two threads hit removeModel() at the same time.

Distributed cache management is one of those areas where the details really matter. A clear layer hierarchy and explicit failure guarantees aren't optional extras — they're what separate a system that works from one that almost always works.

The full source is available in the v1.1.0 release.

If you spotted something I missed or have a different approach to any of these problems, I'd love to hear it in the comments.

I got tired of heavyweight frameworks, so I built my own web server in Java

Mustafa Bingül — Fri, 24 Apr 2026 20:30:58 +0000

I got tired of heavyweight frameworks, so I built my own web server in Java

Most Java web projects start with Spring Boot. You add the dependency, and suddenly you have an entire ecosystem loaded into memory before your first route is even registered. For a lot of use cases that's totally fine. But I wanted something I could drop a JAR into a folder, double-click, and have a running web server in under three seconds — no config ceremony, no classpath drama.

So I built Aurelius.

What is it?

Aurelius is a lightweight, minimalist Java web server designed for developers who want to get a site or a small API running without pulling in a full framework. It runs on Java 8+, ships as a single executable JAR (or .exe on Windows), and is built on top of Netty for the networking layer.

The core idea: drop the JAR in a folder, launch it, put your HTML files in the right place, and you have a running server. That's it.

Project structure

When Aurelius starts, it expects this layout:

my-project/
├── aurelius.jar
├── settings.yml
├── app/
│   └── main.html        ← served at /
│   └── about/
│       └── main.html    ← served at /about
├── containers/
│   └── button.html
│   └── section.html
└── public/
    └── logo.png
    └── data.json

Every folder under app/ becomes a route. main.html in a folder is the index for that route. Files under public/ are served statically and accessible from any HTML file via /public/filename.

The container system

This is the part I'm most proud of. Instead of reaching for a templating engine, I built a simple component system directly into the server.

You define a reusable HTML fragment in the containers/ folder:

<!-- containers/button.html -->
<button class="btn btn-primary">{text}</button>

Then you use it anywhere in your pages with a custom tag:

<container.button text="Click me"></container.button>

Aurelius processes the tag at serve time, injects the attribute values into the fragment, and sends the assembled HTML to the client. No JavaScript required, no build step, no npm.

You can nest containers, pass multiple attributes, and compose entire page sections from reusable fragments. It's not React — it's intentionally much simpler — but for static-ish sites it removes a lot of repetition.

Placeholder system

For site-wide variables, Aurelius has a placeholders.yml file:

title: "My Site"
author: "Mustafa"
version: "1.2"

Anywhere in your HTML you write %title% and Aurelius substitutes it at serve time:

<head>
  <title>%title% — Home</title>
</head>

This is useful for things like site name, meta descriptions, or any string you'd otherwise duplicate across dozens of pages.

RESTful API support via addons

Aurelius isn't just for serving HTML. You can register REST endpoints programmatically through the addon system:

// GET /api/hello
AddonManager.registerRestFulService(
    new RestFulResponseStructure.Builder("hello")
        .setRestFulResponse((body, helper) -> {
            return "Hello, world! Path: " + Arrays.toString(helper.getPathData());
        })
        .setRequestType(RestFulRequestType.GET)
        .build()
);

For structured request/response bodies, you implement the RestFulResponse<Output, Input> interface and Aurelius handles JSON deserialization automatically:

public class UserController implements RestFulResponse<UserDto, UserRequest> {

    @Override
    public UserDto response(UserRequest request, RestFulResponseHelper helper) {
        UserDto dto = new UserDto();
        dto.setUsername(request.getUsername());
        return dto;
    }

    @Override
    public UserRequest convert(String body) throws Exception {
        return (UserRequest) AddonManager.convertFromBodyJson(body, UserRequest.class);
    }
}

Cookies are also supported through the helper:

CookieStructure cookie = new CookieStructure();
cookie.setCookieName("session");
cookie.setCookieValue(UUID.randomUUID().toString());
cookie.setFeatures(Arrays.asList(new CFMaxAge(3600), new CFHttpOnly()));
helper.sendCookie(cookie);

Configuration

All server settings live in settings.yml:

server:
  port: 8080
  threadSize: 4
  ui: true

ui: true enables a built-in management panel where you can start, stop, and reload the server without touching the terminal. Useful if you're deploying somewhere without a great CLI experience.

Framework support

Because Aurelius just serves HTML, it works with any CSS framework that can be loaded from a CDN. Tailwind, Bootstrap, Bulma — just drop the <link> tag in your HTML and it works.

Who is this for?

Aurelius is a good fit if you:

Want a zero-dependency web server for a small internal tool or personal site
Are learning Java web development and want to see how a server works without framework magic hiding everything
Need to prototype a REST API quickly without standing up a Spring application
Want to understand Netty's HTTP handling without writing the boilerplate yourself

It's not the right tool for large production applications with complex routing, authentication middleware, or ORM integration. For those, reach for Spring Boot or Quarkus.

What's next

The main thing on my list is proper test coverage — the container parsing and placeholder substitution logic especially need unit tests. I'm also thinking about WebSocket support and a simple session management API.

11 releases in, Aurelius handles the basics solidly. If you're the kind of developer who likes understanding what's running under the hood, give it a try.

I built a centralized data orchestration engine for distributed Minecraft servers — here's how

Mustafa Bingül — Fri, 24 Apr 2026 20:28:44 +0000

I built a centralized data orchestration engine for distributed Minecraft servers

This post is about a real architectural problem I ran into while working on a multi-server Minecraft network — and how I solved it by building a dedicated data microservice called Nexus Core.

The problem

A large Minecraft network runs many game servers at the same time: lobby servers, PvP arenas, survival worlds, minigame instances. Each one is a separate JVM process running a Spigot plugin. The traditional approach is simple — every server connects directly to MongoDB, manages its own in-memory cache, and handles its own data logic.

This works fine at small scale. At larger scale, three problems emerge:

Connection pool exhaustion. Each server holds its own pool of MongoDB connections. With 20 servers, you're throwing 20× the connections at your database for no good reason.
Cache incoherency. Server A caches a player's balance. Server B modifies it. Server A's cache is now stale. The player sees incorrect data depending on which server they're on.
Duplicated logic. The same data access code exists in every plugin. Changing how player data is structured means touching 15 codebases.

The solution: one service that owns all data

Nexus Core is a standalone Java application that acts as the single source of truth for all data in the network. Game servers never query MongoDB directly. Instead, they publish a structured packet to a Redis channel, and Nexus Core handles the rest.

Spigot #1 ─┐
Spigot #2 ──► Redis (pub/sub) ──► Nexus Core ──► MongoDB
Spigot #3 ─┘

This gives us:

A single, optimized MongoDB connection pool
A centralized Redis cache that all servers read from
Data logic defined once per data type, shared everywhere

The packet protocol

Every request from a game server is a JSON packet published to a Redis channel:

{
  "protocol": 100,
  "source": "pvp-1",
  "type": "GET_DATA",
  "data": { "uuid": "550e8400-e29b-41d4-a716-446655440000" }
}

protocol is a numeric ID that identifies which data type is being requested. source is the server's identifier, used to publish the response back to the right channel. type is one of GET, SET, DELETE, or GET_ALL.

Nexus Core subscribes to the inbound channel, deserializes the packet, and routes it to the right handler in O(1) via a Map<Integer, DataAddon>.

The DataAddon abstraction

A DataAddon is an abstract class that you extend to define a new data type. It maps to exactly one MongoDB collection and one Redis cache namespace. Here's what a minimal addon looks like:

public class PlayerStatsAddon extends DataAddon {

    @Override public int addonId()          { return 100; }
    @Override public String addonName()     { return "Player Stats"; }
    @Override public String getDatabase()   { return "nexus_core_db"; }
    @Override public String getCollection() { return "player_stats"; }
    @Override public String cacheKeyHeaderTag() { return "stats"; }

    @DbDataModels(isId = true)
    private String uuid;

    @DbDataModels(defaultValue = "0", isId = false)
    private int kills;

    @DbDataModels(defaultValue = "0", isId = false)
    private int deaths;

    @Override
    public boolean handleRequest(String source, RequestType type, NexusJsonDataContainer data) {
        return true; // return false to reject the request
    }
}

Nexus Core discovers the schema at boot time via reflection over @DbDataModels annotations. It finds which field is the primary key, reads default values for missing fields, and knows how to serialize/deserialize documents without you writing any mapping code.

Registering the addon is one line:

NexusApplication.getInstance().getProtocolHandler().registerAddon(new PlayerStatsAddon());

From that point on, any game server can send a packet with protocol: 100 and get a full player stats document back.

Request lifecycle

Here's the full flow for a GET request:

Game server publishes packet to Redis
Nexus Core receives it and looks up the addon by protocol ID
handleRequest() is called — if it returns false, an empty response is sent back immediately
Nexus Core checks Redis for key stats:{uuid}
Cache hit → serialize and publish response
Cache miss → query MongoDB, write result to Redis, publish response

SET writes through to both MongoDB and Redis. DELETE removes from both. GET_ALL bypasses cache entirely — caching arbitrary result sets would make invalidation logic very complex.

The handleRequest() interceptor

This is one of my favorite parts of the design. Before any database operation happens, your addon's handleRequest() method is called synchronously. You can inspect the source server, the request type, and the payload — and reject the request outright by returning false.

This is where authorization lives. For example:

@Override
public boolean handleRequest(String source, RequestType type, NexusJsonDataContainer data) {
    if (type == RequestType.REMOVE_DATA) {
        return source.equals("admin"); // only admin server can delete
    }
    return true;
}

Keep this method fast — it runs synchronously and blocks the request pipeline.

Monitoring dashboard

Nexus Core ships with a live monitoring UI built entirely in Java Swing with Java2D — no external libraries. It shows real-time JVM CPU load, process RAM usage, number of objects currently in the Redis cache, and the count of active addons. All rendered as animated donut charts and scrolling line graphs.

What I'd do differently

Looking back, the main thing missing is test coverage. The addon system and cache invalidation logic are exactly the kind of thing that benefits from solid unit tests, and I didn't write them. That's the next thing I'm adding.

I'd also consider replacing the protocol integer with a string identifier — numeric IDs work fine but require a separate constants file to stay readable, which is an avoidable friction point.

Repo

https://github.com/mustafabinguldev/nexus-core

If you're building anything on distributed Java infrastructure or have thoughts on the addon model, I'd love to hear from you in the comments.

Forem: Mustafa Bingül

How I Rebuilt a Three-Layer Cache System in Java — Redis, L1, and MongoDB Done Right

The Architecture: What We're Building

Problem 1: The Hierarchy Was Backwards

The original code

The fix

Problem 2: Silent Data Loss on Flush Failure

The original code

The fix

Problem 3: TOCTOU Race Condition in removeModel()

The original code

The fix

Problem 4: Deadlock Risk in Reconciliation

The original code

The fix

Problem 5: MongoDB Request Storm on Large Datasets

The fix: batch processing

Problem 6: Redis Evict/TTL Was Silently Ignored

The original code

The fix

Problem 7: addModelFix() Left Redis Empty

The original code

The fix

Problem 8: O(n) ID Lookup

The original code

The fix: reverse index

The Final Picture

Takeaway

I got tired of heavyweight frameworks, so I built my own web server in Java

I got tired of heavyweight frameworks, so I built my own web server in Java

What is it?

Project structure

The container system

Placeholder system

RESTful API support via addons

Configuration

Framework support

Who is this for?

What's next

Links

I built a centralized data orchestration engine for distributed Minecraft servers — here's how

I built a centralized data orchestration engine for distributed Minecraft servers

The problem

The solution: one service that owns all data

The packet protocol

The DataAddon abstraction

Request lifecycle

The handleRequest() interceptor

Monitoring dashboard

What I'd do differently

Repo