Scribd Logo
Upload

Welcome to Scribd!

  • 127 views

    MQ Mail - Backend Architecture Design Attachment

    Uploaded by

    kostabongo
    The document describes the backend architecture of an email service called MQ Mail. It uses a third-party service for sending and receiving emails via APIs. The backend consists of an application server and database. It discusses known limitations around performance, features, and bugs to address expected growth.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    MQ Mail - Backend Architecture Design Attachment

    Uploaded by

    kostabongo
    127 views4 pages
    The document describes the backend architecture of an email service called MQ Mail. It uses a third-party service for sending and receiving emails via APIs. The backend consists of an application server and database. It discusses known limitations around performance, features, and bugs to address expected growth.

    Original Title

    MQ_Mail_-_Backend_Architecture_Design_Attachment_(1)

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document describes the backend architecture of an email service called MQ Mail. It uses a third-party service for sending and receiving emails via APIs. The backend consists of an application server and database. It discusses known limitations around performance, features, and bugs to address expected growth.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    127 views4 pages

    MQ Mail - Backend Architecture Design Attachment

    Uploaded by

    kostabongo
    The document describes the backend architecture of an email service called MQ Mail. It uses a third-party service for sending and receiving emails via APIs. The backend consists of an application server and database. It discusses known limitations around performance, features, and bugs to address expected growth.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 4

    MQ Mail - Backend Architecture / Design

    Context
    This interview is a roleplay. We (your interviewers) have recently launched a consumer email
    product in the market, ​MQ Mail​ (to compete with GMail), and need your support in improving our
    backend to meet the expected increase in consumer demand.

    Since we want to compete against Gmail, we have come up with the following Service Level
    Objectives.
    ● 99.99% availability to users
    ● Inbox view in <1000ms at 95th percentile and <500ms at 50th percentile

    What we’ve built so far

    Send & Receive Partnership


    We have established a partnership with an “infinitely scalable” 3rd-party service to send and
    receive emails on our behalf. We interact with this service through simple RESTful APIs.

    Send
    Our 3rd-party partner exposes an endpoint ​“/send”​ which accepts JSON encoded emails via an
    HTTP POST. ​“/send”​ returns a 201 response if the message will be successfully delivered and
    a 5XX upon failure. These responses are ​definitive​.

    Example ​“/send” ​request​:

    $ curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: <something>" \
    --data '​{ \
    "id": "some-mq-generated-unique-id", \
    "to":"foo@bar.com", \
    "from": "baz@mqmail.com", \
    "subject": "Test", \
    "message": "Test test." \
    }​' https://api.3rd-party-service.net/send

    Receive
    Our 3rd-party partner receives (via SMTP) all email for our registered domain (mqmail.com) and
    notifies us upon each email receipt via ​webhook​: a JSON encoded HTTP POST. They will
    retry the webhook for up to 24 hours until receiving a 2XX response from our server.
    Example simulated ​webhook​ request​:

    $ curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: <something>" \
    --data '​{ \
    "id": "some-3rd-party-generated-unique-id", \
    "to":"baz@mqmail.com", \
    "from": "foo@bar.com", \
    "subject": "Test", \
    "message": "Test test." \
    }​' https://api.mqmail.com/receive

    MQ Mail Backend
    We have built a simple backend, which consists of an application server (which serves requests
    from the frontend via RESTful APIs), deployed as a Docker container in “the cloud”, and a single
    relational database server.

    Database Schema
    We have 2 tables in our database. ​users​, which stores the consumer email accounts, and
    emails​, which stores the emails sent and received.

    users​ table

    emails​ table
    Authentication and Authorization
    Our frontend manages authentication and authorization. For the sake of this discussion we can
    assume that each request our backend receives has been appropriately validated and includes
    a simple, performant way to extract a ​user_id​ from it.

    Sending Email
    Our backend receives an HTTP POST to send an email from our frontend and:
    1. Generates a unique id for the email
    2. Formats and sends an HTTP POST to the 3rd-party ​“/send”​ endpoint
    3. Upon success:
    a. Inserts an ​emails​ row into our database
    b. Sends a 201 response to our frontend
    4. Upon failure:
    a. Sends a matching 5XX response to our frontend

    Receiving Email
    When our 3rd-party partner receives an email to our domain on our behalf, they forward it to our
    backend via an HTTP POST (​webhook​) and:
    1. Searches for a matching user record based on the “to” field in the JSON body
    2. Upon finding a matching user:
    a. Generates a unique id for the email
    b. Inserts an ​emails​ row into our database
    c. Sends a 201 response to the 3rd-party
    Known Limitations

    Feature Limitations
    By design, MQ Mail currently does not support:
    1. Multiple recipients
    2. Cc, Bcc
    3. Attachments

    Performance Limitations
    Our system has performed well enough (we think) so far (we have signed up roughly 10K users
    in the 3 months since our launch) but we are concerned about performance as we grow. Our
    goal is to reach GMail size (100M users) over the next year. There are two specific areas that
    concern us:
    1. Application​ ​server availability, latency and load
    2. Database reads and writes, specifically from and to our ​emails​ table

    Major Bugs
    We have intermittently heard complaints from our users about seeing duplicate inbound emails.
    It isn’t reproducible but we do see the duplicate entries in our database in each case (with
    similar timestamps).

    We’ve also heard a few reports of users seeing “strange” error messages when attempting to
    send an email. In each of these cases, when debugging, we have found that the email was
    actually sent to (and received by) the intended recipient. However, the email was not stored in
    our database and not visible in the user’s outbox.

    What we need your help with


    In your conversation with us we will discuss ways to handle our expected growth, add a feature
    or two, and identify / fix these bugs we’ve seen. We don’t expect you to come with a
    presentation prepared but just to have digested this document and be ready to dive into an
    in-depth technical discussion.

    You might also like