A microservice architecture divides an application into independently deployable services, each responsible for a specific purpose. Services can scale horizontally and remain available when individual instances fail. The approach applies the UNIX principle of doing one thing well to distributed applications. section 12.2
A service in this architecture typically:
- Performs one focused action, such as storing configuration or transcoding media. section 12.2
- Scales up or down independently as its workload changes. section 12.2
- Continues operating through problems affecting individual application instances. section 12.2
- Communicates with other services through network protocols or messaging infrastructure. section 12.3
Media transcoding pipeline
A user interface sends uploaded media to an API server. The API stores the media and places a transcoding job on a message queue. Transcoder services consume jobs, write converted files to storage, and enqueue notification jobs. The user interface later retrieves the converted file. A Go service can connect to Kafka, read batches from a media topic, and transcode the media or pass work to another service. section 12.2 section 12.2
Figure 12.3 A simple transcoding application broken into microservices
Trace the upload, storage, queue, transcoding, notification, and download services in the transcoding architecture. section 12.2
Communication becomes a performance concern as the number of services grows. REST over TLS can impose substantial network overhead across a multi-service workflow; faster approaches such as gRPC or a dedicated networking layer can reduce that cost. section 12.3
