Online Transaction Processing

Online transaction processing (OLTP) is a type of database system used in transaction-oriented applications, such as many operational systems. “Online” refers to that such systems are expected to respond to user requests and process them in real-time (process transactions). The term is contrasted with online analytical processing (OLAP) which instead focuses on data analysis (for example planning and management systems).

OLTP systems use a relational database that can do the following:

• Process a large number of relatively simple transactions — usually insertions, updates and deletions to data.
• Enable multi-user access to the same data, while ensuring data integrity.
• Support very rapid processing, with response times measured in milliseconds.
• Provide indexed data sets for rapid searching, retrieval and querying.
• Be available 24/7/365, with constant incremental backups.

Use

OLTP has also been used to refer to processing in which the system responds immediately to user requests. An automated teller machine (ATM) for a bank is an example of a commercial transaction processing application. Online transaction processing applications have high throughput and are insert- or update-intensive in database management. These applications are used concurrently by hundreds of users. The key goals of OLTP applications are availability, speed, concurrency and recoverability (durability).

Package singleflight provides a duplicate function call suppression mechanism.

Data Access Objects (DAO)

Code that depends on specific features of data resources ties together business logic with data access logic. This makes it difficult to replace or modify an application’s data resources.

The Data Access Object (or DAO) pattern:

• separates a data resource’s client interface from its data access mechanisms
• adapts a specific data resource’s access API to a generic client interface

The DAO pattern allows data access mechanisms to change independently of the code that uses the data.

Advantages of DAO pattern

There are many advantages for using DAO pattern. Let’s state some of them here:

1. While changing a persistence mechanism, service layer doesn’t even have to know where the data comes from. For example, if you’re thinking of shifting from using MySQL to MongoDB, all changes are needed to be done in the DAO layer only.
2. DAO pattern emphasis on the low coupling between different components of an application. So, the View layer have no dependency on DAO layer and only Service layer depends on it, even that with the interfaces and not from concrete implementation.
3. As the persistence logic is completely separate, it is much easier to write Unit tests for individual components. For example, if you’re using JUnit and Mockito for testing frameworks, it will be easy to mock the individual components of your application.
4. As we work with interfaces in DAO pattern, it also emphasizes the style of “work with interfaces instead of implementation” which is an excellent OOPs style of programming.

Domain Models

A domain model is a system of abstractions that describes selected aspects of a sphere of knowledge, influence or activity (a domain). The model can then be used to solve problems related to that domain. The domain model is a representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. The concepts include the data involved in the business and rules the business uses in relation to that data. A domain model leverages natural language of the domain.

A domain model generally uses the vocabulary of the domain, thus allowing a representation of the model to be communicated to non-technical stakeholders. It should not refer to any technical implementations such as databases or software components that are being designed.

Composition vs. Inheritance

Composition and inheritance are two ways to achieve code reuse and build complex systems. Inheritance is a mechanism that allows a class to inherit properties and behavior from a parent class. Composition is a way of building complex objects by combining smaller, simpler objects.

In Go, composition is favored over inheritance. This is because Go does not have classes like traditional object-oriented programming languages. Instead, Go uses structs to define objects and interfaces to define behavior. Composition is achieved by embedding one struct into another.

For example, a solution to compose a simple report in Go can be model as follows:

type celsius float64type temperature struct {
    maximum, minimum celsius
}type location struct {
    latitude, longitude float64
}type report struct {
    sol int
    temperature temperature
    location location
} 

Via metasploit

# brew install metasploit

$ msfconsole

msf > use auxiliary/scanner/ipmi/ipmi_dumphashes
msf auxiliary(ipmi_dumphashes) > show options
    ... show and set options ...
msf auxiliary(ipmi_dumphashes) > set RHOSTS ip-range
msf auxiliary(ipmi_dumphashes) > set RHOSTS 192.168.18.30
msf auxiliary(ipmi_dumphashes) > exploit

Scope

Functional Requirements

Here are the basic use cases:

1. URL shortening: given a long URL => return a much shorter URL
2. URL redirecting: given a shorter URL => redirect to the original URL

- Candidate: Can you give an example of how a URL shortener work?
- Interviewer: Assume URL https://www.systeminterview.com/q=chatsystem&c=loggedin&v=v3&l=long is the original URL. Your service creates an alias with shorter length: https://tinyurl.com/ y7keocwj. If you click the alias, it redirects you to the original URL.

- Candidate: How long is the shortened URL? 
- Interviewer: As short as possible.

- Candidate: What characters are allowed in the shortened URL?
- Interviewer: Shortened URL can be a combination of numbers (0-9) and characters (a-z, A-Z).

- Candidate: Can shortened URLs be deleted or updated?  

• Interviewer: For simplicity, let us assume shortened URLs cannot be deleted or updated.

• The link may be expired?

• Can a customer create a tiny url of his/her choice or will it always be service generated ? If user is allowed to create customer shortened links, what would be the maximum size of custom url ?

• Yes user can create a tiny url of his/her choice. Assume maximum character limit to be 16.

• Do we expect service to provide metrics like most visited links ?

• Yes. Service should also aggregate metrics like number of URL redirections per day and other analytics for targeted advertisements.

• what if a long URL already had a short URL? what if a long URL already had a short URL, but the expire is different?

Non-Functional Requirements

• Service should be up and running all the time
• URL redirection should be fast and should not degrade at any point of time (Even during peak loads)

Volumn

• • Candidate: What is the traffic volume?
  • Interviewer: 100 million URLs are generated per day.

• assume reading occurs much more than write? and ratio is 10:1

• Any SLA required? E.g., the SLA of URL redirecting

• Serve globally? need to deploy services to be close to users?

• High availability, scalability, and fault tolerance considerations

Estimation

• Write operation: 100 million URLs are generated per day.
• Write operation per second: 100 million / 24 /3600 = 1160
• Read operation: Assuming ratio of read operation to write operation is 10:1, read operation per second: 1160 * 10 = 11,600
• Assuming the URL shortener service will run for 10 years, this means we must support 100 million * 365 * 10 = 365 billion records.
• Assume average URL length is 100.
• Storage requirement over 10 years: 365 billion * 100 bytes * 10 years = 365 TB