Interview Preparation - Solution Architect
SECURITY
Security Implementation
We can implement the SECURITY in the following ways
1) BASIC Authentication
Its traditional Authentication Approach ,sending the USER Credential to access the Service/Application. USER Credential are in PLAIN text format
2) DIGEST Authentication
Similar to BASIC except the USER Credential are in encrypted Format
3) CERT Authentication
Apart from USER Credential , We are sending the CERT. CERT will procure from third PARTY CERT Authority .Communication between SERVER and CLIENT either its ONE WAY /TWO WAY SSL
Difference between ONE WAY / TWO WAY SSL
One-way SSL authentication is if the client only verifies the certificate of the server. This validation is done to make sure that it is the expected server, i.e. no man in the middle attack.
Two-way SSL authentication (or better mutual authentication or client authentication) is if the server also verifies the certificate of the client. This is done to authenticate the client against the server using a certificate.
PROCESS SSL Handshake
a) Client will send the message to SERVER
b) SERVER will respond with CERT along with Public Key
c) Client Verify the CERT and generate the Share/Master key using the Public Key
d) Client will send the Share/Master key to Server along with CERT(if its two way SSL)
e) Server decrypt the share key with the Private key and verify the the Client CERT (if its two way SSL)
f) Now both parties have Share/Master Key
g) Client will encrypted the message using share key and send to server
h) Server decrypt the message using their Share Key to verify and respond back
Client and SERVER used the common share/master key to protect their communication
4) APP KEY
App Key will generate the in Provider Side and share with Consumer, Whenever Consumer consume the service , need to send the APP Key along with Request either through Query Parameter or in the HEADER . Recommended way to send the APP Key in the Header .
Provider side also implement the App Key Rotation policy ie expire date for those key
5) JWT
JSon WEB Token define in RFC 7159 to protect the data between two parties , In High level
What is RFC 7519
1) Header
Header define the type and alg
2) Payload /Claim
we have different types of Claim , user id/iss/sub/exp and etc
3) Signature
JWT: base64Encode(Header).base64encode(payload).secret key
WE have two parts
Generate and Verify the JWT Token
6) OAuth 2.0
Difference between OAuth and JWT?
SOAP VS REST
SOAP
Simple Object Protocol
Functional Driven
Supports HTTP,SMTP ,UDP and Other
Supports XML
Highly Secure and Transfer large amount of Data
Stateless as default , supports Stateful
Cache not supports as default
WS-Security and Built in ACID Supports
Poor Performance , More complex
Requires more resource and computing power to perform
Use Case :Distributed System,payment gateway ,Telecom with High Security in EA
REST
Data Driven
Supports only HTTP
JSON and XML
Cache enable
SSL Enable for security
Require less resource and High Performance
Easily scalable ,flexible ,high performed
Suits for only Open API ,mobile API and etc.
NO SQL VS SQL
SQL:
Structured Format Data ie Row and Column
Mainly for Transactional Data
Support ACID
Based on the Schema
Supports Complex Queries
Not able store the Hierarchical Data
Scale up
Mostly Vendor /Open Source
NO SQL
Structured and Un Structured
Not suits for Transaction Data
Supports BASE
Dynamic schema
Stored in Key Value/Graph/document and etc
Not supports complex Queries
Stored Hierarchical Data
Scale out
Open Source
API VS SOA
SOA
Mainly used to expose the functionality internally ie integration perspective we can integrate the multiple system and expose the service(s) to internal application
Reduced the Cost perspective, instead of maintaining the redundant services we can create the reused services in organization level
Internal system or partner systems are main consumer
Heavy load and not easy to scale up
Mainly to improve the Process in Organization level
focus the based on the functionality ie what functionality to expose as service with in organization level
API
mainly used to expose our data to public
generating the revenue
developer is main consumers
light weight and easy scalable
Focus the Design based on the user experience or consumers
API Design Goal
all our API should follows 555
5 Mins - access the API and understand the basic capability
5 Hours - play around with API
5 days - create the APP using our API and Push in to PROD
Self service Portal to access our API Spec
reduced the barriers to access our assets through API from outside
Primary consumers are Developers
Security and scalability always in mind
API Strategy
1) Define the Business goal and identify the Business domain
2) Understand the existing IT
3) Create Pilot to expose the Asset to small group with in the organization
4) measure the business objective
5) extend to the API to Partners
6) manage the API Life cycle
Life Cycle Of API
Design
1) Create the User Story
2) Create the API Spec based on the model
3) Generate the mock using the API Spec
4) Push into Sandbox env and share the endpoints with Consumers
5) Update the Spec based on the Feedback from Consumers
6) Spec Sign off
Development
Implement the API
Secure the API
Manage API
Types of API
Private API
Partner -Partner On Boarding process in place to access our API
Public API
We define the Rate plan for Product level ie in our context all our API are bundle with a PRODUCT .We can define the RATE Plan in PRODUCT level and also define the type of API in APP Level(Private /Partners/Public)
API Management will supports, Security layer,Cache,Representation layer, Orchestration layer(if requires)
JSON API Spec:
Problem :
Client have different preference from server
with out clear guidelines , data modal is so messy
misalignment between server and client
Sync between server and client always challenge
Feature of JSON API Spec
1) retrieve the data with related domain in single call using relationship
2) implement the pagination/sort/filtering in request
3) selective fields from response using Sparse Field set
4) Cache and eTag implementation
5) Partial Updates using Patch
VND.api+json , Vendor specific Json
JSON API is a wire protocol for incrementally fetching and updating a graph over HTTP
JSON API is a wire protocol, which means it includes both a format for resources and a specification of operations that you can do on those resources.
JSON API works incrementally, which means clients can fetch data as they need it at the appropriate granularity.
JSON API defines a way for both fetching and updating because modifying resources often is just as important as fetching them.
JSON API defines a graph structure, which enables data to be linked together in a well-defined way.
JSON API works over HTTP, which means JSON API uses the HTTP protocol—including its caching semantics—as its backbone.
Domain Driven Design
GraphQL:
MSA :
Identifying the MS:
1) Functional based
2) Data Driven
3) Request Driven
Steps to involve( We have two scenarios a)developing MS in newly b) developing MS from existing service)
b) Developing MS from existing service :
b1) Identify the Coarse grained Services
b2) decompose into small Coarse grained Services( based on the Functionality )
b3) Maps those small Coarse grained Services into DB Table(Data Driven Approach) , here we will fine tune the granulatery level in those services
b4) Refine the Service Granularity
b5) Identify the Dependent services ie inter communication between those services
b6) refine the service granularity based on the customer request (Request Driven) ..
We need to repeatly from step B4--> B6 to fine grained the service granularity
Coarse Grained VS Fine Grained
Orchestration VS Choreography
Contract Versioning in MSA:
pass the Version number in Query Parameter, Here we are implementing the version in end point level ie different URL for each version
Pass the version in Header ,no changes requires in URL.
Orchestration and Aggregator in MSA:
Check Sum ?
Circuit Breaker Pattern :
increase performance and responsiveness in your microservices (or any remote) application.
Types of CB implementation
1) Heart Beat
2) Synthatic Transaction ie Fake Transaction
3) REal time monitoring
MS Gateway Pattern
Reporting in MS:
Loosly Coupling
* WorkFlow
* Error Handling
* Data Consistency Issue
* Transaction state management
Event Driven Architecture :
Cloud Native Architecture :
Command Vs Query
How do we get the Response from ASync Call ?
REactive
Service Design Pattern
Direct Access Design
API Access Design
API Layer --> Service(API) -->Backend Modules
Distributed logging
Splunk/logstash and etc
Two Types of Distributed logging
Log Consolidation
Log Stream
Distributed logging
Splunk/logstash and etc
Two Types of Distributed logging
Log Consolidation
Log Stream
Comments
Post a Comment