Data-oriented architecture

  • In data-oriented architecture (DOA), systems are still organized around small, loosely coupled components as in services-oriented architecture with microservices. However, the components are always stateless and component-to-component interaction is minimized so that they interact through a data layer instead.
  • Common examples that approximate DOA include those using data monoliths where all or most data is persisted in a single store, such as knowledge graphs or GraphQL.
  • If you are worrying about scaling your architecture horizontally, you can consider a data monolith at its center and base your decision on these factors:
  1. Service-to-service APIs are not necessarily ad hoc, but it is easier to pass parameters in direct component-to-component communication.
  2. Beware if your system has integration as a bottleneck, as it will affect growth.
  3. Think hard about data ownership: multiple writers might have to modify the same record so you need to partition write ownership.
  4. Carefully plan the shared global schema because inter-component APIs are encoded in the data.
  5. If services call others with a direct address (like an IP) and know where to reach a particular service from command-line parameters, you need to wrap those better to construct the right flags, depending on the environment (say, structuring each service under a path routed by one server).

Full post here, 10 mins read