4 Application Technical Specification Length: 2-3 pages At a high-level you’ll b
ID: 3751554 • Letter: 4
Question
4 Application Technical Specification Length: 2-3 pages At a high-level you’ll be running a web server that connects to a database and also serves a publicly available list of API methods. First, which web server would you use and why? Next, which database would you use and why? Assume the dataset is large, but not huge. The data contains natural relationships that should support fast search. The data also has a pre-existing, well-defined schema that will not change over time. Think carefully about what these data specs. mean when choosing a DB engine (relational, key-store, document-based, etc.). With respect to the DB server, how would you run it: inside of an EC2 instance, in a container, in a pre-existing Amazon service? Please give specific details that support your decision. How would you make the web and database server fault-tolerant? We’d also like to hear how you intend to keep these services online while performing routine scanning and maintenance on them? Which tools would you use to scan your chosen web server and database server? Why did you choose these tools and how would you configure them to minimize (or eliminate) downtime? Recall the website also offers a set of REST API’s to its users. Namely, it will offer a /GET method that allows someone to GET a JSON list of users and their, say, financial transactions. A /DELETE method is also supported that allows a user to delete their bank account in the event they decide to close it down. Finally, there is a /POST method that allows a user to add authorized party to their account so the newly added members can view historical transaction data. What technology would you use to implement such an API? There is clearly no security baked into this API, so please discuss the risks of just publishing the API as it is written here? What steps would you take to secure the API against malicious access?
Explanation / Answer
Choice of Web Server - Apache Tomcat Server I would use SSL TLV 1.2 enabled tomcat server . As it is built with HTTP server and servlet engine that serves dynamic pages on runtime to the user using JSP technology. For serving static files php or cgi we could use apache server with SSL enabled . Use of nginx for load balancer is also the best option as it really efficient in serving static html files and could be used as cache also. Use of memory tuning occupies very low memory overhead , since it is java is platform independent runs and deploy everywhere mentality and open source no licensing cost and those overheads. Database engine choice- I would deploy database in a separate tier or separate container away from the tomcat engine for security with firewall enabled. The database for search would be relational database with +Btree indexing which offers fast lookups. Choice of index selection should be restricted to one or two columns. I would use Amazon Aurora MySQL engine as it is Solid State Drive and is very efficient for search and provide fast lookups in O(logn) time with 1/10th of the cost.Amazon aurora comes with its own hosting (t1.micro till t1.large) and also has serverless option which autoscales to 64TB based on the load. Web and Database Fault Tolerant - No single point of failure - Replicate the Web servers to different regions 6 replicas over different regions is advisable and write scripts that support automatic leader election. Database use cloning and sharding if it is a very large database. Clone to different regions and for write heavy workloads use cassandra , for read only there isn't required for locking (lock free) . Use cachedb by netflix or redis cache for caching the request if it fails. We’d also like to hear how you intend to keep these services online while performing routine scanning and maintenance on them? Answer - Use request throttling , use context switch or HAProxy loadbalancer that offers you to route traffic to healthy instances where maintenance could be performed on other instances. Use serverless to scale your apis if the load becomes more on the servers that is accepting external traffic. Which tools would you use to scan your chosen web server and database server? Why did you choose these tools and how would you configure them to minimize (or eliminate) downtime? Answer: Portscanner , HAproxy (load balancer ) , Tomcat Self Healer , Zookeeper. HAproxy is a proven http loadbalancer with 99.999% availability . Please refer docs . Zookeeper is a service discovery and automatic leader election tool . Please refer docs. Recall the website also offers a set of REST API’s to its users. Namely, it will offer a /GET method that allows someone to GET a JSON list of users and their, say, financial transactions. A /DELETE method is also supported that allows a user to delete their bank account in the event they decide to close it down. Finally, there is a /POST method that allows a user to add authorized party to their account so the newly added members can view historical transaction data. What technology would you use to implement such an API? There is clearly no security baked into this API, so please discuss the risks of just publishing the API as it is written here? What steps would you take to secure the API against malicious access? Use spring boot , jax-rs , spring security to build the REST (GET,DELETE,PUT,POST) services. Use encryption enabled MySQL DB , store the customer data in encryption format (SHA-2 or RSA) is industry standard. Don't hardcode security tokens in your applications , HTTPS is mandatory , SSL certificates has to be created from trusted authority and should be authenticated on both sides. Run inside docker containers that will provide you added security. AWS has secure vault that lets you gets the public crypto tokens and add your details and send it across. USE VPN and Virtual Private Cloud with firewall built and finally run inside dedicated hosts.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.