System Requirements

Functional:

1. Translate inputted language to the target language
2. Detect input language based on provided text
3. Support multiple languages

Non-Functional:

1. Offline Mode
   1. Support being able to translate when offline
2. Availability
   1. We prioritize availability over consistency
   2. We want our service to be highly available
3. Latency
   1. The translated text should appear in at max a second
4. Scalability
   1. Be able to serve a large number of queries each second
   2. Be able to serve spikes in traffic

Capacity estimation

1. We assume that the service has to deal with 100,000 concurrent users at a time
2. Each user submits 100 words on average, meaning we have to translate 10^7 words
3. Let us assume that our system can translate 10 words per second
4. We assume that each translation requires 10 MB of data
5. Thus, throughput = 10^7 / 10 = 10^6 words per request
6. Memory needed is 10^5 * 10 * 10^6 = 10^12 bytes of data = 1 GB data

API Design

1. /translate
   1. GET
   2. Takes in a block of text as input in the form of a JSON. This block of text is what we have to translate. Also takes in the input language and output language as parameters
   3. Returns a JSON which has the translated text that is the result of the conversion

Database Design

1. We assume that a translation engine is doing the translation for us. The only data store we need would be a cache that will store the translations for commonly requested translations
2. For that purpose we can store that data in a cache in a database or in a content delivery network

High-Level Design

flowchart TD

client[Client] --> loadBalancer{Load Balancer}

loadBalancer --> apiGateway[API Gateway]

apiGateway --> messageQueue[Message Queue]

messageQueue --> translationService[Translation Service]

translationService --> translationEngine[Translation Engine]

translationService --> translationCache[Translation Cache]

Request Flows

1. User sends a block of text to be converted to the target language, passes through the API Gateway which routes it to the message queue
2. The message queue passes the request to the translation service
3. The translation service first looks up the translation in the cache, if it is found, it is returned
4. If data is not found in the cache, we hit the translation engine, get the translation, populate the result in the cache and send the result to the user

Detailed Component Design

1. Our API gateway can also implement rate limiting to protect against distributed denial of service attacks
2. Our cache can use the least recently used policy. That way only the most recently searched terms will stay in the cache. Older results not used recently will be evicted
3. For our translation engine we can use a third party service like Amazon or Google or we can make up our own
4. To build our own translation engine, we would take the steps given below.
   1. Input Processing
      1. The translation engine receives the input text or speech data in the source language that needs to be translated
      2. It may involve preprocessing steps such as tokenization, normalization, and cleaning to prepare the input for translation
   2. Language Detection
      1. The engine might perform language detection to identify the source language if not provided
      2. Language detection will help determine the appropriate translation model to use for converting the text to the target language
   3. Translation Models
      1. Utilizing machine translation algorithms like Neural Machine Translation (NMT) or Statistical Machine Translation (SMT), the engine converts the input text into the target language
   4. Context and Meaning
      1. The translation engine takes into account the context, grammar, and semantics of the input text to produce meaningful and contextually appropriate translations
   5. Quality Evaluation
      1. The translated output may undergo quality assessment processes to evaluate the accuracy and fluency of the translation using metrics like BLEU score or human evaluation
   6. Post Processing
      1. Additional post-processing steps like fluency adjustments, grammar corrections, or context-based optimization can be applied to refine the translated output
   7. Output Generation
      1. The final translated text or speech output is generated and presented to the user in the desired target language through the user interface or delivery mechanism
5. Google Translate leverages NMT models, which are deep neural networks trained to directly map input text in one language to the desired output text in another language
6. NMT models consider the context of the entire sentence rather than translating it word-by-word, leading to more accurate and fluent translations
7. We can have an offline translation engine or incorporate pre-trained language models within the client-side application to perform translations locally without the need for a network connection.
8. Cache frequently used translations or store recently translated phrases locally on the user's device to allow for quick retrieval and offline access without requiring re-translation.
9. This also means that the client would first utilize offline translation whenever it can and only make request when offline translation isn't sufficient

graph LR A[Input Text or Speech] --> B(Language Detection) B --> C{Translation Engine} C --> D(Translation Models) D --> E(Context Analysis) E --> F(Quality Evaluation) F --> G{Post-Processing} G --> H[Translated Output]

Trade Offs/Tech Choices

1. For our messaging queue, we use Apache Kafka since it is a log based message broker meaning in cases of failure of the message queue, data is not lost
2. For our cache, we can use an in memory database like Redis which will allow fast reads

Failure Scenarios/Bottlenecks

Future Improvements

1. Ability to pronounce the result of the translation