The document discusses various software design patterns including the external configuration pattern, cache aside pattern, federated identity pattern, valet key pattern, gatekeeper pattern, circuit breaker pattern, retry pattern, and strangler pattern. It provides descriptions of each pattern, examples of problems they aim to address, and considerations for applying the patterns. Taswar Bhatti presents on these patterns and takes questions.

1. TaswarBhatti

2. Ponder
• For every 25 percent increase in problem complexity, there is a
100 percent increase in solution complexity.
• There is seldom one best design solution to a software problem.
• If cars were like software, they would crash twice a day for no
reason, and when you called for service, they’d tell you to
reinstall the engine.
@taswarbhatti

3. Who am I
• Taswar Bhatti – Microsoft MVP since 2014
• Global Solutions Architect/System Architect at Gemalto/Thales
• In Software Industry since 2000
• I know Kung Fu (Languages)
@taswarbhatti

5. Agenda
• What are Patterns?
• The External Configuration Pattern
• The Cache Aside Pattern
• The Federated Identity Pattern
• The Valet Key Pattern
• The Gatekeeper Pattern
• The Circuit Breaker Pattern
• The Retry Pattern
• The Strangler Pattern
• Questions
@taswarbhatti

6. Bad Design
@taswarbhatti

7. Bad Design
@taswarbhatti

8. Bad Design
@taswarbhatti

9. Bad Design?
@taswarbhatti

10. Itunes when I use it
@taswarbhatti

11. What are Patterns?
• General reusable solution to a recurring problem
• A template on how to solve a problem
• Best practices
• Patterns allow developers communicate with each other in well
known and understand names for software interactions.
@taswarbhatti

12. External Configuration Pattern
@taswarbhatti

13. External Configuration Pattern
• Helps move configuration information out of the application
deployment
• This pattern can provide for easier management and control of
configuration data
• For sharing configuration data across applications and other
application instances
@taswarbhatti

14. Typical Application
@taswarbhatti

15. Storing Configuration in file
@taswarbhatti

16. Multiple application
@taswarbhatti

17. Problems
• Configuration becomes part of deployment
• Multiple applications share the same configuration
• Hard to have access control over the configuration
@taswarbhatti

18. External Configuration Pattern
@taswarbhatti

19. When to use the pattern
• When you have shared configuration, multiple application
• You want to manage configuration centrally by DevOps
• Provide audit for each configuration
@taswarbhatti

20. When not to use
• When you only have a single application there is no need to use
this pattern it will make things more complex
@taswarbhatti

21. Cloud Solution Offerings
• Azure Key Vault
• Vault by Hashicorp
• AWS KMS
• Keywhiz
@taswarbhatti

22. Cache Aside Pattern
@taswarbhatti

23. Cache Aside Pattern
• Load data on demand into a cache from datastore
• Helps improve performance
• Helps in maintain consistency between data held in the cache
and data in the underlying data store.
@taswarbhatti

24. Typical Application
@taswarbhatti

25. Cache Aside Pattern
@taswarbhatti

26. When to use the pattern
• Resource demand is unpredictable.
• This pattern enables applications to load data on demand
• It makes no assumptions about which data an application will
require in advance
@taswarbhatti

27. When not to use
• Don’t use it for data that changes very often
@taswarbhatti

28. Things to consider
• Sometimes data can be changed from outside process
• Have an expiry for the data in cache
• When update of data, invalidate the cache before updating the
data in database
• Pre populate the data if possible
@taswarbhatti

29. Cloud Offerings
• Redis (Azure and AWS)
• Memcache
• Hazelcast
• Elastic Cache (AWS)
@taswarbhatti

30. Federated Identity Pattern
@taswarbhatti

31. Federated Identity Pattern
• Delegate authentication to an external identity provider.
• Simplify development, minimize the requirement for user
administration
• Improve the user experience of the application
• Centralized providing MFA for user authentication
@taswarbhatti

32. Typical Application
@taswarbhatti

33. Problem
@taswarbhatti

34. Problem
• Complex development and maintenance (Duplicated code)
• MFA is not an easy thing
• User administration is a pain with access control
• Hard to keep system secure
• No single sign on (SSO) everyone needs to login again to
different systems
@taswarbhatti

35. Federated Identity Pattern
@taswarbhatti

36. When to use
• When you have multiple applications and want to provide SSO
for applications
• Federated identity with multiple partners
• Federated identity in SAAS application
@taswarbhatti

37. When not to use it
• You already have a single application and have custom code
that allows you to login
@taswarbhatti

38. Things to consider
• The identity Server needs to be highly available
• Single point of failure, must have HA
• RBAC, identity server usually does not have authorization
information
• Claims and scope within the security auth token
@taswarbhatti

39. Cloud Offerings
• Azure AD
• Gemalto STA and SAS
• Amazon IAM
• GCP Cloud IAM
@taswarbhatti

40. Valet Key Pattern
@taswarbhatti

41. Valet Key Pattern
• Use a token that provides clients with restricted direct access to
a specific resource
• Provide offload data transfer from the application
• Minimize cost and maximize scalability and performance
@taswarbhatti

42. Typical Application
Client App Storage
@taswarbhatti

43. Problem
Client App Storage
Client
Client Client
Client
@taswarbhatti

44. Valet Key Pattern
Client App
Generate Token
Limited Time
And Scope
Storage
@taswarbhatti

45. When to use it
• The application has limited resources
• To minimize operational cost
• Many interaction with external resources (upload, download)
• When the data is stored in a remote data store or a different
datacenter
@taswarbhatti

46. When not to use it
• When you need to transform the data before upload or
download
@taswarbhatti

47. Cloud Offerings
• Azure Blob Storage
• Amazon S3
• GCP Cloud Storage
@taswarbhatti

48. Gatekeeper Pattern
@taswarbhatti

49. Gatekeeper Pattern
• Using a dedicated host instance that acts as a broker between
clients and services
• Protect applications and services
• Validates and sanitizes requests, and passes requests and data
between them
• Provide an additional layer of security, and limit the attack
surface of the system
@taswarbhatti

50. Typical Application
@taswarbhatti

51. Problem
@taswarbhatti

52. Gatekeeper Pattern
@taswarbhatti

53. When to use it
• Sensitive information (Health care, Authentication)
• Distributed System where perform request validation separately
@taswarbhatti

54. When not to use
• Performance vs security
@taswarbhatti

55. Things to consider
• WAF should not hold any keys or sensitive information
• Use a secure communication channel
• Auto scale
• Endpoint IP address (when scaling application does the WAF
know the new applications)
@taswarbhatti

56. Circuit Breaker Pattern
@taswarbhatti

57. Circuit Breaker Pattern
• To handle faults that might take a variable amount of time to
recover
• When connecting to a remote service or resource
@taswarbhatti

58. Typical Application
@taswarbhatti

59. Problem
@taswarbhatti

60. Client
Circuit
Breaker
Api
Closed State
Timeout
Closed State
Open State
Half Open State
After X Retry
Closed State
@taswarbhatti

61. Circuit Breaker
@taswarbhatti

62. When to use it
• To prevent an application from trying to invoke a remote service
or access a shared resource if this operation is highly likely to fail
• Better user experience
@taswarbhatti

63. When not to use
• Handling access to local private resources in an application, such
as in-memory data structure
• Creates an overhead
• Not a substitute for handling exceptions in the business logic of
your applications
@taswarbhatti

64. Libraries
• Polly (http://www.thepollyproject.org/)
• Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
@taswarbhatti

65. Retry pattern
@taswarbhatti

66. Retry Pattern
• Enable an application to handle transient failures
• When the applications tries to connect to a service or network
resource
• By transparently retrying a failed operation
@taswarbhatti

67. Typical Application
Network Failure
@taswarbhatti

68. Retry Pattern
• Retry after 2, 5 or 10 seconds
@taswarbhatti

69. When to use it
• Use retry for only transient failure that is more than likely to
resolve themselves quicky
• Match the retry policies with the application
• Otherwise use the circuit break pattern
@taswarbhatti

70. When not to use it
• Don’t cause a chain reaction to all components
• For internal exceptions caused by business logic
• Log all retry attempts to the service
@taswarbhatti

71. Libraries
• Roll your own code
• Polly (http://www.thepollyproject.org/)
• Netflix (Hystrix) https://github.com/Netflix/Hystrix/wiki
@taswarbhatti

72. Demo
@taswarbhatti

73. Strangler Pattern
@taswarbhatti

74. Strangler Pattern
• Incrementally migrate a legacy system
• Gradually replacing specific pieces of functionality with new
applications and services
• Features from the legacy system are replaced by new system
features eventually
• Strangling the old system and allowing you to decommission it
@taswarbhatti

75. Monolith Application
@taswarbhatti

76. Strangler Pattern
@taswarbhatti

77. When to use
• Gradually migrating a back-end application to a new
architecture
@taswarbhatti

78. When not to use
• When requests to the back-end system cannot be intercepted
• For smaller systems where the complexity of wholesale
replacement is low
@taswarbhatti

79. Considerations
• Handle services and data stores that are potentially used by
both new and legacy systems.
• Make sure both can access these resources side-by-side
• When migration is complete, the strangler façade will either go
away or evolve into an adaptor for legacy clients
• Make sure the façade doesn't become a single point of failure or
a performance bottleneck.
@taswarbhatti

80. Questions?
Taswar Bhatti
System Solutions Architect (Gemalto/Thales)
Microsoft MVP
http://taswar.zeytinsoft.com
@taswarbhatti
@taswarbhatti