6 Common services for functional partitioning

 

This chapter covers

  • Centralizing cross-cutting concerns with API gateway or service mesh/sidecar
  • Minimizing network traffic with a metadata service
  • Considering web and mobile frameworks to fulfill requirements
  • Implementing functionality as libraries vs. services
  • Selecting an appropriate API paradigm between REST, RPC, and GraphQL

Earlier in this book, we discussed functional partitioning as a scalability technique that partitions out specific functions from our backend to run on their own dedicated clusters. This chapter first discusses the API gateway, followed by the sidecar pattern (also called service mesh), which was a recent innovation. Next, we discuss centralization of common data into a metadata service. A common theme of these services is that they contain functionalities common to many backend services, which we can partition from those services into shared common services.

NOTE

Istio, a popular service mesh implementation, had its first production release in 2018.

Last, we discuss frameworks that can be used to develop the various components in a system design.

6.1 Common functionalities of various services

6.1.1 Security

6.1.2 Error-checking

6.1.3 Performance and availability

6.1.4 Logging and analytics

6.2 Service mesh/sidecar pattern

6.3 Metadata service

6.4 Service discovery

6.5 Functional partitioning and various frameworks

6.5.1 Basic system design of an app

6.5.2 Purposes of a web server app

6.5.3 Web and mobile frameworks

6.6 Library vs. service

6.6.1 Language specific vs. technology-agnostic

6.6.2 Predictability of latency

6.6.3 Predictability and reproducibility of behavior

6.6.4 Scaling considerations for libraries

6.6.5 Other considerations