Geode is a toolkit for Java—it is not a server product.

Status

Legacy

Context

Shall Geode be a server product or a (Java) toolkit?

Traditional client-server database and web application caching products provide thin or fat client libraries. In those systems there is a clear separation between clients, which run user-defined code plus a client library/framework, and servers, which run in processes defined wholly by product code. If those servers provide for execution of user-defined code, that execution happens solely under the control of product code.

Users of these traditional client-server products are shielded from server-side implementation choices such as product implementation language, so long as suitable client libraries are available. This is a key choke-point in such architectures. By narrowing client-server communication through a (assumed small, stable) network protocol—many different client technology stacks can be supported, and much freedom to evolve the server implementation is gained.

The Geode product documentation describe two topologies: client-server, and peer-to-peer.  The client-server topology aligns most closely with what administrators and developers coming from widely-used database products and web application caching products have come to expect. But the so-called peer-to-peer support in Geode offers a wide variety of configuration possibilities beyond that.

As a low-latency, consistent in-memory caching product, Geode must (almost by definition) provide at least a "fat client" library. In order to provide low-latency, consistent caching, changes must be propagated synchronously, and data must be made available in-process (in the user application process). Clients cannot, in general, wait for a network round-trip for data reads. This implies that in the client-server mode, Geode must have a sophisticated fat client library. Geode, in fact provides two such fat client libraries: a Java one and a "native client". Each of these fat client libraries provides a language-level or link-level interface for client programs to communicate via IP networking, to a server (cluster). The fat client libraries provide sophisticated in-process data management.

A decade-and-a-half ago, the software on which Geode is based, started life as a shared object memory. There was no client-server mode at all. There was only peer-to-peer. In that world the software's raison d'être was to provide efficient, low-latency, consistent data replication between processes. All processes were assumed to be Java virtual machines, and in fact, all processes were assumed to run software written entirely in Java. Some of the most significant users of the software on which Geode is based, have business-critical high-scale applications that rely entirely on this use of the software to support peer-to-peer data management.

Decision

Geode is a Java toolkit—not a server product. While Geode supports a client-server topology, and therefore supports clients written in various programming languages, it also supports a peer-to-peer topology. This peer-to-peer support a primary focus. No effort will be made to abstract a peer-to-peer interface away from the current implementation. Peers are Java programs.

Consequences

Geode exposes a vast peer-to-peer Java API that users rely on. The Geode project benefits from no single client-server choke-point in the architecture.

It would be very difficult to significantly change Geode's server-side (peer-to-peer) architecture. Furthermore, it would be very difficult (and almost nonsensical) to change Geode's server-side implementation language. Contrast this with PostgreSQL or Redis or RabbitMQ.

Format

This GAP format is based on Michael Nygard's ADR Template.