Mongo cluster fb-mongod starts out as a database which stores flight related data and configurations. Due to growth of Traveloka products, currently it stores booking data not only for flight, but also for various other products. While the newer products have moved on to store booking data on their own databases, lots of the older products are still storing agent.booking on fb-mongod.
Disk Free (1 May 2018) : 790 GB
Storage Size (1 Jan 2018) : 1050 GB
Storage Size (1 May 2018) : 1290 GB
Data Growth Rate : 60 GB / month
Major contributor : agent.booking
Estimated Disk Exhausted : June 2019
Dashboard : https://app.datadoghq.com/dash/447238/fpr-fb-mongod---mongod?live=false&page=0&is_auto=false&from_ts=1512061200000&to_ts=1526662799999&tile_size=s&fullscreen=false
Please refer to below tables for estimation on the traffic that accommodation will be handling:
Product Write Rate Read Rate Row Count Not Verified Booking Notes
HOTEL 200 / min 25K / min 65.698.807 40.009.586
Source: https://29022131.atlassian.net/wiki/spaces/USER/pages/763167191/TDA+Agent+Booking+Migration+Guide#id-[TDA]AgentBookingMigrationGuide-ImplementTripItineraryAccessorandAgentBookingViewAccessor
Now every product must own it's agent booking data, Accommodation demand team plans to have a dedicated service owner, also new database is needed to store the data too.
This new service ("aprubd") will serve it's function as data layer service which will provide basic function to do CRUD. And this service is only exposed to accomodation product.
The main purpose is to migrate agent booking data that relate to accommodation out from fb-mongod to our accommodation team specific infra in order to derisking fb-mongod before capacity deadline has been reached, derisking products from cascading failure when degradation happens on a shared resource, having proper layer of data provider and fetching method for access from non-product clients, and proper booking data ownership.
By having this infrastructure it will give accommodation team one step closer to decommission of fb-mongod (one of big shared resource on tvlk) and also multi account.
No risk to current infrastructure. It will be a risk when not having this infra. When maximum capacity has been reached for fb-mongod then our ability to handle normal traffic might be downgraded or even worse.
count = "3"
instance_type = "r4.2xlarge"
ebs_optimized = "true"
disable_api_termination = "false"
root_block_device = {
volume_type = "gp2"
volume_size = "8"
delete_on_termination = "true"
}
tags = {
Service = "aprubd"
Cluster = "aprubd-mongod"
ProductDomain = "apr"
Application = "mongod-3.0"
Environment = "production"
Description = "mongoDB instance for accom agent booking data"
}
encrypted = "true"
size = "4800"
type = "gp2"
device_name = "/dev/sdf"
tags = {
ProductDomain = "apr"
Environment = "production"
Mount = "/var/lib/mongod"
Description = "mongoDB storage for accom agent booking data"
}
count = "1"
instance_type = "r4.2xlarge"
ebs_optimized = "true"
disable_api_termination = "false"
root_block_device = {
volume_type = "gp2"
volume_size = "8"
delete_on_termination = "true"
}
tags = {
Service = "aprubd"
Cluster = "aprubd-mongohs"
ProductDomain = "apr"
Application = "mongod-3.0"
Environment = "production"
Description = "mongoDB instance for accom agent booking data hidden secondary"
}
encrypted = "true"
size = "4800"
type = "gp2"
device_name = "/dev/sdf"
tags = {
ProductDomain = "apr"
Environment = "production"
Mount = "/var/lib/mongod"
Description = "mongoDB storage for accom agent booking data hidden secondary"
}