SOFTWARE ARCHITECTURE -VIVEK RIKHARI

1
Purpose Of the System
This Software Architecture is for one of the leading trading platforms (XYZ- Keeping it confidential). The specific
feature will explain generation of business or legal documents (CONTRACT NOTE- https://groww.in/blog/what-is-a-
contract-note-how-to-interpret-it) once trade transaction has been successfully placed by the end customer.

FEATURES

1. Identify the type of instrument (Commodities, FX, Equities, Cryptos) for which the transaction has been made
2. Generate documents (including invoices, contract note) in the format defined by business/legal.
3. Data should be encrypted at rest.
4. Should be elastic and able to support at least 75K documents per day.
5. Should be shared with third party vendors through SFTP (SSH file transfer protocol)

2
 REQUIREMENT OF THE SYSTEM

Functional Requirements
- The document service will be responsible for below defined XML creations
- XML files will be transferred to 3rd party Vendor (‘X’), who will help the company with the generation of final terms and condition
documents for the transactions and integrating with regulators on behalf of the online trading company.
- This transfer would be done through SSH File transfer protocol.
Scenarios Supported XML Types Format for the file Number of XMLs File Name Format
When update happens on MFID, KID and PRIPS Defined by the legal team Ideally 1 XML for each MFID_Product-
transactions like overnight having details like closing underlying instruments (FX, ID_TimeStamp
stock charges, stock price time, opening time, first equity)
adjustments, knockouts or trade date, Eg- (i) For every 200 key KID_Product-ID_TimeStamp
selling product_commercial name. metric indexes in the market
create one XML file PRIPS_Product-
(ii) If its more than 800 then ID_TimeStamp
use the following formula
=ROUNDUP(Key Metric
Indexes/200)
When new transaction is Standard Issue Same as above (Defined by Same as above; except that Standard_Product-
created the business/ legal team) the key metrics indexes IC_TimeStamp
threshold becomes 400
MFID & PRIPS Same as above (Defined by Same as above; except that MFID-PRIPS-New-
the business/ legal team) the key metrics indexes IC_TimeStamp
threshold becomes 60
KID Same as above (Defined by One XML for each language KID-New-Language-Product-
the business/ legal team) where the company is ID_TimeStamp
3
functioning
REQUIREMENT OF THE SYSTEM

Non Functional Requirements

1. Volume
Expected to have number of XML creations up-to 100K per day.

2. Performance and Scalability

3. Resilience and Availability

99.9% availability should be achieved having clustered nodes of Document Service
Availability is required throughout the day so that XML can be sent to 3rd party vendor as other dependent service can rely
on and releases can be made in a day

4. Security
Data should be encrypted at rest

5. Administration and Management

Logging and alerting should be enough for inspecting the flow and alerting. Logging is expected to follow common logging
guidelines for capturing IDs

6. Dashboard should demonstrate

1. System Throughput
2. Failure Scenarios 4
3. Other interesting facts
 QUESTIONS FROM THE ASSIGNMENT

Questions Slide No

1. Identify top 3 Architecturally Significant Requirements (ASRs) and write them in the form of a Utility 6,7
tree. Why are these architecturally significant?
2. Describe in detail, the tactics you recommend for each ASR. For example, if caching is a tactic you 8
recommend, please mention what you will cache, what tool you would use, how it will work, etc.
3. Draw 2 software architecture diagrams – component & connection view and deployment view – to 11,12
understand how the system works.
4. Indicate important messages between components by labelling the connections in the C&C view. Also 11
indicate the communication method used.
5. Draw a sequence diagram for one major scenario (use case). Mention the scenario. 9,10
6. State the architecture patterns used. Explain, wherein the architecture, these patterns have been used. 14
7. What did you learn by doing this assignment? Mention 3 key learnings. One slide per person. 15

5
 TOP 3 ARCHITECTURALLY SIGNIFICANT REQUIREMENTS
Based on the discussions in the forum, I have decided to identify following three ASRs as the most
critical ones.

1. SECURITY: We need to have extreme confidentiality while managing these documents as it has
legal/business implications.
2. MODIFIABILITY: There would be frequent legal/business guideline revisions in such businesses.
Hence, its must that modifiability should be focused thoroughly in this architecture.
3. AVAILABILITY: Minimal service outage time is critical for ensuring customers use this platform.
Hence, error handling and fault detection (part of Availability) becomes key ASR for this
architecture.

We also debated on whether usability, performance or testability can be among the top 3, but decided
against it. While we realize these ASRs are also critical, but security, modifiability and availability are key
to ensure that basic functional and user requirements are met.

6
Utility Tree For 3 Key Architecturally Significant Requirement
Quality Attributes Attribute Refinement ASR
Security Confidentiality Data should be encrypted and locked.

Integrity A user can access only his trade related documents and not for anyone else (Message
Integrity)

Audit Trail Maintain audit trail in case of any business/legal concerns.

Availability Error Handling Exception handling- For instances when either the system is not able to fetch required
file from specific location or if transaction fails
Fault Detection Heartbeat- identifies any network or system failure of nodes
Modifiability Increase cohesion Use design patterns which allows you to add more features to existing module with
minimum changes to the existing architecture
Reduce Size of a module Use split module to ensure fast reaction to any changes owing to a change in the
legal/business requirement

7
Tactics used to achieve top 3 ASRs
1. SECURITY
<Resist Attacks→ Authenticate actors, Authorize Actors , Encrypt data>
Use Case – Business wanted to have extreme confidentiality while managing the files as it had legal implications.
Hence, we have made SSL certifications as compulsory for downloading the documents. All the documents are password
protected and cannot be retrieved by anyone else including the company employees.

2. AVAILABILITY
<Detect Faults→ Heart Beat; Recover from Faults→ Exception Handling and Active Redundancy>
Use Case 1- In the scenario of error (data unavailability), the business wanted the transaction to happen as usual. Else
it would have created panic among the end users. Hence, we enabled exception handling in our modules that ensures
that transaction happen as usual. Further we also run duplicate instances (BLUE AND RED- Refer Deployment Diagram)
to ensure seamless functioning incase one of the instance fails. In parallel we also integrated ‘HEARTBEAT’ in our
application which monitors the uptime of the application.

3. MODIFIABILITY
<Reduce Size of a Module→ Split Module>
Use Case 1- There was a new legal guidance for generating new set of data points having TPIN details. As we built the
new feature, the business ask was to run the system as is and do not impact the existing architecture as it would impact
the customer experience. Hence we had multiple/split modules.
8
UI Document Service 3rd Party Vendor Database KAFKA BUS

Transaction Details
Complete transactions
Submit the transaction details

Listen to the transaction details

Commit the details

Standard Issue – Only for new transactions

Create 1 XML for each underlying instruments (FX, equity)

SFTP XML File transfer to 3P vendor

KID Issue – New or updated transactions in different language

Create 1 XML for each underlying language

SFTP XML File transfer to 3P vendor

MFID/PREP ISSUE– Only for updated transactions

Create 1 XML for each underlying instruments (60 transactions)

SFTP XML File transfer to 3P vendor

UI
High level Sequence Diagram- Scenario explanation in the next slide 9
Explanation of a scenario for the Sequence Diagram
STEP 1- User performs a transaction (buying and selling of a stock) and an event is triggered.

STEP 2-Document Service Application subscribe to KAFKA topics , which send the details of the event.

STEP 3- This request is handled by the document service and the document is generated as per the details of the
transactions and predefined business formats.
STEP 3a. If transaction is placed for the first time by the user, STANDARD ISSUE document is generated for each
underlying instrument.
Step 3b. If transaction is in different language (European languages), KID is issued.
Step 3c. If some corrections/strike adjustments are being made in the transaction, then MFID/PREP issue is done

STEP 4- Once the document is generated, its key information is saved in the database.

STEP 5- The generated documents will be in the form of pdf and saved in the cloud in the encrypted form.

STEP 6- The document is then made available to the third party vendor through SFTP XML File transfer.

Key Acceptance Criteria

1. Documentation and Demo

2. Showcase of recovery during the broken system instance
3. Load Test and Acceptance test to be met 10
 Communication method (Apache Kafka)
Transaction event

KAFKA BUS

DOCUMENT SERVICE
DOCUMENT DATABASE
SFTP

3rd Party Vendor

COMPONENT AND CONNECTION DIAGRAM

And Communication Method 11
 KAFKA BUS
Transaction Event

USER

Monitoring Logging Scheduling Monitoring Logging Scheduling

Load Balancer Load Balancer

BLUE INSTANCE RED INSTANCE

SFTP SFTP

CLOUD THIRD PARTY VENDOR DATABASE

DEPLOYMENT DIAGRAM 12
UNDERLYING COSTS
Language

OFFERING COUNTRIES

Exchange

DOCUMENT DATA
PRODUCT

Issuer Details
TRANSACTION_DATE

DECOMPOSITION DIAGRAM
(Data flow model- the system is decomposed into functional modules which transform inputs to outputs) 13
Architecture Patterns Used
1. Client-server pattern
a. There are two parties involved ; a server (which is providing the event details) and client (3rd party)
b. Clients request services (documents) from the server and the server (document service) provides relevant services
(documents in required format) to those clients.
c. The server continues to listen to client requests (whenever a new event is triggered).

2. Event-bus pattern
a. There are four sources here: event source (instrument management), event listener (document service), channel
(topic) and event bus (Kafka).
b. Sources publish messages to particular channels on an event bus. Kafka is being used here.
c. Listeners subscribe to the instrument management application.
d. Listeners are notified of messages that are published to the topic to which they have subscribed before.

Channel
Source Listener
(Event Bus)

14
KEY LEARNINGS
1. Non Functional Requirements are key for building any new architecture. This helps us understand the business
expectations.
1a. The Software Architecture should take into consideration the future requirements and expansion plans.
1b. Software architecture also helps in prioritizing conflicting goals. It helps stakeholders understand the
consequence of their stated requirement.

2. Focus on the ASR while building a new architecture is must to ensure that the system works as per the
expectation and is resilient enough to tackle any unknown events in future.
2a.Software architecture should ensure transferability of the model. It should have the ability to be reused for
additional use cases.
2b. A big architecture should be split down into different microservices to ensure parallelization of the work . This
allows relevant teams to work on different modules as per their skills
2c. Component connections and deployment diagrams should be designed with long term planning as they are
not easily modifiable later

3. A good and detailed Software Architecture plan helps developers build efficient modules.
3a. Software architecture plan helps in making early business decisions as well as feasibility of the system. Hence
we should make it as detailed as possible.
3b. A good software architecture in addition to improving the performance also reduces cost and impacts quality
of deliverables. 15