The document discusses various patterns and concepts in distributed application design, focusing on scalability, service architecture, and data consistency. Key topics include service-oriented approaches, microservices, high availability, authentication, and different communication methods between services. It also highlights the importance of load balancing, service discovery, and eventual consistency in modern software architectures.

1. Distributed Application Design
Patterns & Concepts

2. Speaker
Orkhan Gasimov
Digital Transformation Architect & Coordinator of
Architecture Practice in GlobalLogic Ukraine
• Over 17 years of software engineering;
• Focused at enterprise and solution architecture levels;
• Specialized in front, back and data layers covering
wide range of technology stacks and approaches;
• Mentoring & teaching, author of training courses;

3. Basic Concepts
Problem Statement

4. Application
• A set of features delivered to end users.

5. Client-Server
• Client – the application used by end users.
• Server – the backend application used by client apps.

6. Multitier
• A client-server app with physically separated layers.
• Presentation;
• Application Processing;
• Data Management;

7. Excessive client connections
• How do we scale if there are too many client connections?

8. Load Balancer
• Scale to multiple instances behind a load balancer.
• Potential bottlenecks… database?

9. Scalability
• What is shared?
• Clients share Server apps;
• Server apps share Database;

10. Scalability
• What is shared?
• Clients share Server apps;
• Server apps share Database;
• Shared resources:
• CPU, Memory, Disks...
• What else?

11. Scalability
• What is shared?
• Clients share Server apps;
• Server apps share Database;
• Shared resources:
• CPU, Memory, Disks...
• What else?
• Pareto principle:
• 80/20 rule.

12. Evolution
Service-Oriented Approach
(not Architecture, not SOA, but SO*)

13. Service-Oriented
• Services are deployed separately.

14. Service-Oriented
• Services are scaled independently.

15. Cascading Calls
• Services may reuse other services.

16. Load Balancing
• Do we need a Load Balancer per Service?

17. Service Discovery
• Service Registry:
• Services registers at startup and provide heartbeats.
• Registry knows location of each services (all instances).
• Services access services directly, Registry is an address-book, not proxy.

18. Load Balancing with Service Discovery
• Server-side Load Balancing:
• Discovery Server returns a single instance (e.g. round-robin).
• Client-side Load Balancing:
• Client fetches list of all instances and decides which to use.

19. Discovery Cluster
• Single point of failure:
• Discovery Server (service registry) may fail.
• Discovery Server Cluster is required.

20. Dynamic Scalability
• Deploy more instances to scale on the fly.

21. API Gateway
• Proxy API or Expose specific API (a service as API Gateway).
• Or proxy always and create new services for specific API.

22. Patterns so far…
• Service Discovery
• Client-side
• Server-side
• API Gateway
• Proxy
• Programmed
• Load Balancer
• Client-side
• Server-side

23. High Availability

24. High Availability

25. High Availability

26. High Availability

27. High Availability

28. High Availability

29. High Availability

30. • Regions
High Availability

31. • Availability Zones
High Availability

32. • All services available.
High Availability

33. • All instances of a service are not available in local zone.
High Availability

34. • All instances of a service are not available in local region.
High Availability

35. • All services recovered after fail.
High Availability

36. Architectural Styles

37. Layers
• Services are organized into layers, each layer performing a specific
role within the application.

38. Microservices
• Services form a single application.
• Independently deployed, horizontally scaled and dynamically coordinated;

39. SOA
• Applications are provided to the other components as services.
• Support independence of vendors, products and technologies.

40. Security Concerns

41. Authentication
• Authentication is the process of confirming the identity.
• Is requestor really represents the identity claimed?

42. Authorization
• Authorization is the function of specifying access rights to resources.
• Does requestor have all necessary privileges?

43. Communication
• Data could be stolen while being transmitted.
• Is communication secure enough?

44. Implementation Details
• Roles available:
• User, Client;
• Auth Service;
• Service Provider;
• Common concerns:
• Latency;
• Bottlenecks;
• Statelessness;
• Single Sign-On;
• Fine-grained authorization;
• Exposure of user credentials;

45. Capability-Based
• A capability (key) is a communicable, unforgeable token of authority.
• It references an object along with an associated set of access rights.
• It is used to access another object.

46. Protection Rings
• System is secured using protection rings.
• Diametrically opposite to capability-based security.

47. Communication

48. Direct
• Services communicate with other services directly:
• Coordinated by a discovery server for dynamic scalability.
• Client-side load balancing option available.
• Requires strict contract.
• Remote services should be highly available.
• May cause data loss in case if requests fail.

49. Decoupled
• Services communicate though a middleware:
• Coordinated by the middleware.
• Scaled using such concepts as Partitioning & Consumer Groups.
• Data-oriented, almost contract-free.
• Middleware should be highly available.
• No data loss, middleware can keep it.

50. Synchronous
• Block and wait for answer upon request.
• Standard model to fetch data.
• Blocking API.

51. Asynchronous
• Fire-and-forget model.
• Best suited for action triggers.
• Non-blocking API.

52. Communication
Direct Decoupled
Synchronous
Asynchronous

53. Data Microservices
The Concept

54. Data Microservices
• Basic properties:
• A lightweight data-oriented service;
• Has an input and/or output;
• May play role of sink, source or processor;
Source O SinkIProcessorI O

55. Data Microservices
• Advanced properties:
• Almost contract-free (no methods, just data);
• Decoupled (know nothing about others);
• Reusable (anytime, anywhere);
• Used in composition of pipelines (workflow);

56. Data Microservices: Scalability
• Consumer Groups.
• Scale the architecture at consumer side when there is a demand for more
computational power (high volume of incoming messages, slow consumer).
Publisher
Group: Grey
Consumer 1
Group: Yellow
Consumer 1 Consumer 2Consumer 2

57. Data Microservices: Scalability
• Partitioning.
• Scale the architecture at producer side when there is a demand for more
parallelism at middleware.
Publisher 2
Group: Grey
Consumer 1
Group: Yellow
Consumer 1 Consumer 2Consumer 2
Publisher 1 Publisher 3
1 2 3

58. Data Consistency

59. Transactional Consistency
• Using a transaction manager.

60. Transactional Consistency
• Using a transaction manager.

61. Transactional Consistency
• Using a transaction manager.

62. Transactional Consistency
• Using a transaction manager:
• We heavily depend on it;
• It delays the processing of our transactions (potential bottleneck);
• Complex to implement;
• More complex when we need to communicate with another system.

63. Transactional Consistency
• When dealing with transactions:
• Think about different approaches for different business processes;
• A transaction manager with two phase commit is not always required;
• Actor/event oriented approaches are available as well.
• Coffee shop example.

64. Eventual Consistency
• Event Sourcing:
• Save events of state changes instead of state itself.
• Reconstruct an entity’s state by replaying events.
• Saving an event is a single operation, it is inherently atomic.
Create Account Edit User Name Delete Account

65. Eventual Consistency
• Event Store:
• Events are immutable, store full history, provide a detailed audit trail.
• Events are published to subsystems notifying about the changes to the state.
• Rewind to the state of the system at any previous point in time.
Event Store
Group: Grey
Consumer 1
Group: Yellow
Consumer 1 Consumer 2Consumer 2

66. Eventual Consistency
• Retrieval of state is time consuming.
• Have to replay events to rebuild the state.
• Solution is to maintain two separate models:
• write model — the event store.
• read model — the database.
• A different handler is responsible for updating the read model, once an event
is persisted in the event store (write model).
Write
Model
Read
Model
Events

67. Eventual Consistency
• CQRS:
• every method should either be a command that performs an action,
• or a query that returns data to the caller.
• Return a value only if there are no side effects.
• If you have a return value you cannot mutate state.
• If you mutate state your return type must be void.
Command Query

68. Eventual Consistency
• Event Sourcing + CQRS
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor

69. Eventual Consistency
• Event Sourcing + CQRS
• Consistency:
• Write model is consistent, events are ordered, transactions are simple.
• Most systems can be eventually consistent on the Query side.
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor

70. Eventual Consistency
• Event Sourcing + CQRS
• Consistency:
• Write model is consistent, events are ordered, transactions are simple.
• Most systems can be eventually consistent on the Query side.
• Data Storage:
• Normalized data on the Command side (e.g. a relational structure).
• Denormalized data on the Query side (e.g. to minimize the number of joins).
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor

71. Eventual Consistency
• Event Sourcing + CQRS
• Consistency:
• Write model is consistent, events are ordered, transactions are simple.
• Most systems can be eventually consistent on the Query side.
• Data Storage:
• Normalized data on the Command side (e.g. a relational structure).
• Denormalized data on the Query side (e.g. to minimize the number of joins).
• Scalability:
• Scale Command and Query sides separately.
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor

72. Summary

73. Summary
API Gateway
Discovery
Servers
Command
Service
Query
Service
Event
Store
Data
Store
Data
Store
Command
Service
Command
Service
Query
Service
Query
Service

74. Out of Scope (1)
• Think about:
• Security
• High Availability
• Communication
API Gateway
Discovery
Servers
Command
Service
Query
Service
Event
Store
Data
Store
Data
Store
Command
Service
Command
Service
Query
Service
Query
Service

75. Out of Scope (2)
• Multi-Domain systems
• Several contexts
• Several entry points
• More decoupling
API Gateway
Discover
y Servers
Command
Service
Query
Service
Event
Store
Data
Store
Data
Store
Command
ServiceCommand
Service
Query
ServiceQuery
Service
API Gateway
Discover
y Servers
Command
Service
Query
Service
Event
Store
Data
Store
Data
Store
Command
ServiceCommand
Service
Query
ServiceQuery
Service
Event Bus

76. Thank You!
Patterns of Distributed Application Design