The document discusses the evolution and architecture of microservices, comparing them to the F1 pit stop for efficiency. It highlights key characteristics such as loose coupling, independent scaling, and the importance of APIs for communication, while also noting benefits and challenges associated with microservices. It emphasizes best practices including decentralized data storage and isolation of failures through an API gateway.

1. Systango Tech Talk
The A to Z of Microservices
Architecture

2. Evolution of F1 Pit Stop

3. F1 Pit Stop - Early Days

4. F1 Pit Stop - Today

5. What is a Microservice?
Loosely Coupled Service Oriented Architecture with Bounded Context

6. What is Microservice?
Update Service Independently
Updating one service doesn’t require changing other service
Loosely Coupled Service Oriented Architecture with Bounded Context

7. What is Microservice?
Services Communicate with each other over network
Loosely Coupled Service Oriented Architecture with Bounded Context

8. What is Microservice?
Self Contained -
You can update code without knowing about other Microservices
Loosely Coupled Service Oriented Architecture with Bounded Context

9. Let's start with a Problem statement

10. Designing a new system
● Backends for Admin and Consumer
● Different Services
○ Notification Service - email & push notification
○ Admin API server
○ User API server
● Database

11. Architecture

12. Putting together
Database
Admin Backend
User Backend
NotificationService
Queue
Service
Auth Service

13. Proposed Architecture

14. Key Points
● Small, discrete, independent, loosely coupled and having bounded
context
● Separate codebase, which can be managed by a small development
team.
● Services are responsible for persisting their own data or external state.
● Services communicate with each other by using well-defined APIs.
● Services don’t need to share the same technology stack, libraries, or
frameworks

15. Benefits
● Loose coupling
● Encourage continuous refactoring and rewriting
● Lower dependency on a single technology
● Scale Independently
● Localise failures
● Can be released on independent release cycles

16. Constraints
● Complexity
● Lack of governance
● Network congestion and latency
● Data integrity
● Skillset

17. Practices
● Model services around the business domain.
● Decentralize everything
● Data storage should be private
● Services communicate through APIs — Avoid leaking implementation details.
● Avoid coupling between services
● Offload cross-cutting concerns to the gateway.
● Isolate failures

18. Encapsulating the Microservices

19. API Gateway

20. API Gateway importance
● It Isolates the microservices
● Provides security
● Reduces the number of requests/roundtrips.
● Holds the logic of calling multiple APIs
● Translates from a “standard” public web-friendly API protocol to
whatever protocols are used internally.

21. Contact us to discuss
MICROSERVICES ARCHITECTURE
www.systango.com
hello@systango.com
UK: +44 1253 547777
KNOW MORE ABOUT MICROSERVICES