- 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:
- Service-to-service APIs are not necessarily ad hoc, but it is easier to pass parameters in direct component-to-component communication.
- Beware if your system has integration as a bottleneck, as it will affect growth.
- Think hard about data ownership: multiple writers might have to modify the same record so you need to partition write ownership.
- Carefully plan the shared global schema because inter-component APIs are encoded in the data.
- 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