0% found this document useful (0 votes)
20 views

Software Architecture - Class Projects PDF

The document outlines requirements for six different projects: 1) an enterprise scale monitoring tool, 2) a social network data structure service, 3) a messaging service, 4) a graph database, 5) rearchitecting a web server, 6) a financial risk system. The requirements focus on supporting large amounts of data and users, high availability, scalability, and flexibility.

Uploaded by

Prabhat V
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views

Software Architecture - Class Projects PDF

The document outlines requirements for six different projects: 1) an enterprise scale monitoring tool, 2) a social network data structure service, 3) a messaging service, 4) a graph database, 5) rearchitecting a web server, 6) a financial risk system. The requirements focus on supporting large amounts of data and users, high availability, scalability, and flexibility.

Uploaded by

Prabhat V
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Proj – 1 : Propose an architecture for an enterprise scale monitoring tool

Your design should support following requirements.

- Support a wide variety of data sources


- Able to maintain timeseries of observed data
- Should not require any special or expensive hardware/servers
- Should be able to collect millions of data points every hour
- Exposes an API to view historic as well real-time data as graphs, reports and dashboards
Proj – 2 : Design a data structure for a social network

Design a high availability service to structure social networks, This service should allow
searching for an individual, and then locate shortest path to the searched person. Think six
degrees of separation.

Service should be designed to support skewed network. Some searches are more popular than
others.

Graph data is large and will not fit on a single machine. All connections in the graph are treated
as bi-directional. If I know you, you know me as well.

Service should support approx. 100 million users, 50 friends per user average with SD of 40. It
should support 1 billion friend searches every month.
Proj – 3 : Propose an architecture for a service that can scale to millions of connections,
think whatsapp, or skype.

Your design should support following requirements.


1. Service should allow one-on-one chat, as well as group chat
2. It allows users to maintain contacts and indicate their presence
3. Service should allow offline messages ensuring that no messages are lost
4. Service should allow VOIP based call
5. Service should allow end-to-end chat encryption
6. Authentication and address book integration
7. Service provide notifications for messages sent, delivered and read
8. Service notifies last seen timestamp
Proj 4 - Propose an architecture for building a graph database

Your design should support following requirements.

A graph database is a database that uses graph structures for semantic queries with nodes, edges,
and properties to represent and store data. A key concept of the system is the graph (or edge or
relationship). The graph relates the data items in the store to a collection of nodes and edges, the
edges representing the relationships between the nodes. The relationships allow data in the store
to be linked together directly and, in many cases, retrieved with one operation.

- The database should have a version which can be used in-memory.


- It should have a query language to support various graph operations.
- It should be able to support adding new nodes, relationships and other attributes.
- Graph traversal should be independent of the size if graph.
- It should be possible to serialize the graph database and then load/recover when needed.
- It should be able to be horizontally scaled when needed
Proj – 5 : Re-architecting web (http) server

Your design should support following requirements.

■ Remote access across networks. Any information had to be accessible from any device.
■ Heterogeneity. The system could not be limited to run on any specific hardware or software
platform.
■ Non-centralization. In the spirit of a human web and of the Internet, there could not be any
single source of data or services.
■ Access to existing data. Existing databases/documents had to be accessible.
■ Ability for users to add data. Users should be able to “publish” their own data on the Web,
using the same interface used to read others’ data.
■ Private links. Links and nodes had to be capable of being privately annotated.
■ Live links. Given that information changes all the time, there should be some way of updating
a user’s view of it. This could be by simply retrieving the information every time the link is
accessed or (in a more sophisticated fashion) by notifying a user of a link whenever the
information has changed.
■ High performance. A popular Web site will typically have tens of millions of “hits” per day,
and users expect low latency from it. Customers will not tolerate the site simply refusing their
requests.
■ High availability. E-commerce sites are expected to be available “24/7.” They never close, so
must have minimal downtime—perhaps a few minutes per year.
■ Scalability. As Web sites grow in popularity, their processing capacity must be able to
similarly grow, to both expand the amount of data they can manage and maintain acceptable
levels of customer service.
■ Security. Users must be assured that any sensitive information they send across the Web is
secure from snooping. Operators of Web sites must be assured that their system is secure from
attack (stealing or modifying data, rendering data unusable by flooding it with requests, crashing
it, etc.).
■ Modifiability. E-commerce Web sites change frequently, in many cases daily, and so their
content must be very simple to change.
Proj – 6 : Architect a Financial Risk System

Your design should support following requirements for a mid-size bank. There are existing
systems which will be used to retrieve/source data/information.

1. Import trade data from the Trade Data System.


2. Import counterparty data from the Reference Data System.
3. Join the two sets of data together, enriching the trade data with information
about the counterparty.
4. For each counterparty, calculate the risk that the bank is exposed to.
5. Generate a report that can be imported into Microsoft Excel containing the risk
figures for all counterparties known by the bank.
6. Distribute the report to the business users before the start of the next trading day
(9am) in Singapore.
7. Provide a way for a subset of the business users to configure and maintain the
external parameters used by the risk calculations.

You might also like