We have RFCs (see Project Proposals and Specifications) for proposing and recording significant changes to Geode. But we only started writing those in spring of 2019. Geode was open sourced in 2015-2016 and the software on which it is based was mature over a decade before that! On what guiding principles is this software based?

Well, the agilist would say: read the code. That answer is unsatisfactory if we want our project to be inviting to new contributors. There's just to much code for that answer to be practical.

The purpose of this branch of the wiki is to bring together a cohesive set of pages, each illuminating a design decision already embodied in the software.

Design Decisions

Geode Design Decisions are children of this page. Here's an automatically-generated list of them:

Candidate Design Decision

This section functions as a list of research questions. If you are wondering about a design decision add it here! If you are knowledgable (or a good researcher!) grab something from the list and flesh it out. As these are fleshed-out into pages they can move up into the design decisions section above.

  • Provide a low-latency path on par with (contemporary) competitive offerings. Give examples of key adjacent decisions supporting this one. What are we trading off here, i.e. what are we giving up in order to minimize latency?
  • Provide for efficient immediate consistency. How does this shape the Geode architecture? How would it be different if we were focused only on eventual consistency?
  • Geode is not opinionated—it is a toolkit that can be configured for a broad range of use cases. This is exemplified by the plethora of configuration options, topologies, and region types.
  • Recycle a process instead of failing fast: Geode has an "auto-reconnect" feature and by default it is enabled. The opposite of this principle would be "fail fast". This feels like an anti-pattern and should be changed!
  • Geode implements concurrent tasks using Java Threads directly. Geode code, at every level, creates threads and creates runnables that are run on executors.
  • Give every thread its own socket for P2P but pool sockets for client-server: Geode has a "conserve-sockets" setting for P2P communication. The best-practices recommendation is to turn this off. Until version 1.10, Geode had a "thread-local connections" feature on the client for client-server communication. That feature was recently removed. It seems like we are gravitating toward connection-pooling for client-server communication and away from connection-pooling for P2P communication. There is a lot of lore here about tradeoffs between resource efficiency and latency. What forces are driving the architecture at these two interfaces (client-server and P2P.)
  • <your candidate design decision goes here>

Structure of a Design Decision

Architecture Decision Records look good: https://adr.github.io

Relationship to RFCs

We have RFCs (see Project Proposals and Specifications) for deliberating on changes to the software. But that process and structure is not appropriate for capturing the corpus of past architectural decisions embodied in the software. As we expose more of these legacy decisions we expect we'll want to change some of them. That should yield new RFCs. In the end though, both RFCs and  Design Decisions may be useful to keep around. The former is a vehicle for change. The latter is a description and explanation of the current state.

  • No labels