System requirements

Functional:

1. Translate input text from source language to desired language
2. Convert speech to text (for translation)
3. Detect source language
4. Provide multilingual user-facing service

Non-Functional:

1. Scalability
2. Consistency (two users should not see different translation results)
3. Availability (>99.99% uptime)

Capacity estimation

• 1 million active users / day
• 5 million translation requests daily

There is no storage requirement for this problem. We will serve ~60 requests / sec, which will put load on the translation model but not a db. There is no concept of a db write.

API design

POST translate text:

/api//translations/text

create text translation request body:

• source language (optional)
• desired language (required)
• message (required)

POST translate speech:

/api//translations/speech

create speech translation request body:

• source language (optional)
• desired language (required)
• audio upload url (required)

Database design

N/A

High-level design

There are two components required by both translation flows (text and speech): language detection and translation.

Language detection will use an underlying, pre-trained NLP model. The input to this model will be text, the output will be the detected language. There may be a pre-defined list of supported languages.

Translation will also use an underlying, pre-trained NLP model. The input to this model will be text, source language, and desired language; and the output will be text. There may be a pre-defined list of supported languages.

The text translation flow will call these two components sequentially. The speech translation flow will require two more initial components:

1. Uploading an audio file to blob storage for processing.
2. A third NLP model with an audio file input that outputs text.

Request flows

/api//translations/text:

1. Routing
2. Load distributer
3. Service:
   1. If source language is not defined, detect source language using model
   2. If source or desired language is not supported, return error
   3. Pass source language, desired language, text into translation model
   4. Return results

/api//translations/speech:

1. Upload audio to blob storage
2. Routing
3. Load distributer
4. Service:
   1. Run speech -> text on audio file
   2. If source language is not defined, detect source language using model
   3. If source or desired language is not supported, return error
   4. Pass source language, desired language, text into translation model
   5. Return results

Detailed component design

Language detection: if the text file is large, it may not be effective to run language detection on the entire input. Instead, maybe we can define a minimum text requirement to effectively determine language and pass in a snippet of that size.

Speech -> text: this may be a slow process, especially on a large audio file. Maybe we can run speech -> text as an async process and inform the user when their translation is ready using webhooks or websockets.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

• Make copies of the translation model to horizontally scale requests
• Make speech -> text async to avoid blocking requests on expensive tasks
• Use chunks of text translation when possible to avoid expensive computation at once

Failure scenarios/bottlenecks

Translation requests could fluctuate based on different factors such as geographical regions, time zones, and user demand spikes due to events like international conferences or webinars.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

• Use geographically-located copies of the model with resourcing to serve the mostly highly requested languages in the area
• Hand-train aspects of the NLP models to support edge cases
• Support multi-lingual UI rendering for global users