SOFTWARE ARCHITECTURE -Vivek Rikhari

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 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) 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)
 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 us helping my company with the generation of final terms and condition
documents for the transactions and integrating with regulators on behalf of my 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
transactions like overnight stock
charges, stock price adjustments,
knockouts or selling
MFID, KID and PRIPS Defined by the legal team
having details like closing time,
opening time, first trade date,
product_commercial name.
Ideally 1 XML for each MFID_Product-ID_TimeStamp
underlying instruments (FX,
equity) KID_Product-ID_TimeStamp
Eg- (i) For every 200 key metric
indexes in the market create PRIPS_Product-ID_TimeStamp
one XML file
(ii) If its more than 800 then use
the following formula
=ROUNDUP(Key Metric
Indexes/200)

When new transaction is created
Standard Issue Same as above (Defined by the
business/ legal team)
MFID & PRIPS Same as above (Defined by the
business/ legal team)
KID Same as above (Defined by the
business/ legal team)
Same as above; except that the Standard_Product-
key metrics indexes threshold IC_TimeStamp
becomes 400
Same as above; except that the MFID-PRIPS-New-IC_TimeStamp
key metrics indexes threshold
becomes 60
One XML for each language KID-New-Language-Product-
where the company is ID_TimeStamp
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

• System Throughput
• Failure Scenarios
• Other interesting facts
Utility Tree For 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.

Performance Scheduling Policy Scheduler should run at scheduled time to enable generation of documents
automatically.
Resource Management Retention period for documents
Increased concurrency
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
Testability Internal monitoring Number of documents generated successfully
Modifiability Increase cohesion Use design patterns which allows you to add more features to existing
module with minimum changes to the existing architecture
Tactics used to achieve top 5 ASRs

1. SECURITY

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. PERFORMANCE

Use Case1- Owing to the high volume of transactions across WW markets, we have implemented SPRING/QUARTZ
Schedulers for automatic generation of documents after a scheduled time.

Use Case2- Owing to usage of private cloud, efficient storage was a major criteria while building this architecture. We
connected with business and understood that documents beyond 1 year of transaction time are not required and not
considered legally relevant (usually the tax period). Hence, we have defined the retention period (480 days) after
which old documents get erased automatically
 Tactics used to achieve top 5 ASRs

3. AVAILABILITY

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.

4. TESTABILITY

Use Case 1- One of the major requirement of any trading portal is to monitor the transactions that happened
during the day and accordingly tally it with the legal documents generated. Hence, we built an internal tracker
that ensures that we monitor this data point continuously

5. MODIFIABILITY

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.
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

CONTEXT DIAGRAM – High level Sequence Diagram

 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)
 Transaction event

KAFKA BUS

DOCUMENT SERVICE
DOCUMENT DATABASE
SFTP

3rd Party Vendor

COMPONENT AND CONNECTION DIAGRAM

 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
How the System Works

1. User performs a transaction (buying and selling of a stock) and an event is triggered

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

3. The details of the event is saved in the DB

4. Document service generates the document based on the predefined business formats.

5. The key information of the document is saved in the database

6. The generated documents will be in the form of pdf and saved in the cloud in the encrypted form.

7. In parallel it is send to the third party vendor through SFTP

Key Acceptance Criteria of the architecture

1. Documentation and Demo

2. Showcase of recovery during broken system instance

3. Load test and acceptance test to be met

KEY LEARNINGS

1. Non Functional Requirements are key for building any new architecture. This helps us understand the business
expectations.

2. The Software Architecture should take into consideration the future requirements and expansion plans.

3. 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.

4. A good and detailed Software Architecture plan helps developers build efficient modules.

5. 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.

6. Software architecture should ensure transferability of the model. It should have the ability to be reused for
additional use cases.

7. A good software architecture in addition to improving the performance also reduces cost and impacts quality of
deliverables.

8. Software architecture also helps in prioritizing conflicting goals. It helps stakeholders understand the consequence
of their stated requirement.