project-proposal-2025

Homely

Abstract

When looking for a house to rent or buy, you’ve likely come across websites like realestate.com.au and domain.com.au where you can filter through options based on basic physical properties of a house. However, there’s a lot more to consider than just the number of bedrooms and bathrooms where manually computing this trade-off between properties can take hours.

Homely is a web-based application that calculates and delivers a rating on available houses in a user’s desired area based on criteria that are important to them. For example, a young family might prioritise living near a top 10 rated primary school, whereas a student would prefer to live in a area where 24/7 public transport is readily available.

This project will focus on the qualities of scalability, interoperability and extensbility (respectively):

• would allow for thousands of users to use the application at once without performance drop-offs
• would allow for consistent interaction with external APIs and data lakes
• would allow developers to easily replace or extend certain modules

Ensuring these three qualities are cruical so Homely can handle peak usage traffic, have correct data pulls from external APIs and be able to quickly adapt to user’s new preferences over time.

Author

Name: Bhavya Malik

Student number: 47488407

Functionality

1. Users choose their area and criteria

• input a desired area or suburb (for example: South Brisbane)
• users are presented 10 sliders each corresponding to a different criteria which they can adjust according to their priority
• some of this criteria includes: proximity to highly rated schools, proximity to public transport, house age, neighbourhood safety

2. Score Generation

• uses multiple data sources like the realestate.com.au API and Google Maps API
• calcualtes a score (dependent on criteria) for every available property in the user’s area

3. House Display

• displays an interactive map or list format, where each house is displayed along with the calcualted score
• should be able to choose 2 houses and have them displayed side-by-side to view features
• users should also be able to directly view the listing on the respective platform for inspection times, etc

Example Data Flow:

Scope

Front-End:

The home page should be designed so that the user is first asked their desired location and then given the option to choose between 1-10 on 10 different criteria according to their priority. The next page should display a list or interactive map of the available properties in that area all with a generated score next to them. The user should also be able to directly go to the platform where the property was orginally posted. Further, you should be able to choose two properties and compare the photos and description of the properties side by side. The user should have the capabiltiy to go back and change their preferences wihtout having to refresh the link.

Back-End:

The logic of the scoring engine is out of scope for this project. We simply pass the input parameters to an OpenAI GPT and it calculates and returns the score for that individual property. The reason behind this is that to get accurate scores, we would need to use a variety of machine learning technqiues and learning how to apply them is not a focus of this course.

Data Integration:

We can either use realestate.com.au or domain.com.au’s APIs for the house data as they have the most properties in the Australian market. For the location data, we use the Google Maps API and dependent on what criteria the developer chooses we could use online data sources for more information.

Quality Attributes

1. Scalability

It’s important for Homely to be a well scaled application to be able to handle traffic at peak times (on the weekend or evenings). Having low latency and quick page load times are crucial in a user-facing web application such as this. One way performance can be measured is by overloading the system and analysing at what number of users response time starts to decrease. Additionally, we could find the throughput of the system by measuring how many requests can be handled per second.

2. Interoperability

Since the application heavily relies on various external APIs and data lakes, ensuring Homely consistently pulls the correct data in a format that can be recognised by the system is crucial. A way this could be measured is by caclulating the percentage of succesful API calls relative to total API calls. Since frequent syncs with the realestate.com.au database are important so users can see newly added postings, we could also measure the time taken for a new posting to be visible on Homely.

3. Extensibility

Over time, it’s likely that new criteria will come into consideration when buying or renting a property, so it’s cruical for Homely to be adaptable in adding new factors into the scoring engine. Additionally, as Homely is heavily reliant on external data, we should be able to replace these data lakes and APIs with alternatives in the case of system failures. This can be measured by how much of the codebase/modules needs to be modified in order to be compatiable with a different data provider. Further, we could also measure the amount of time taken for a developer to add another criteria into the scoring engine.

Why did I not priortise the other quality attributes?

• Availbility - though uptime is important, for example, if we choose to do system updates at 2am a very small percentage of people will be affected who can reaccess the website at a later time
• Deployability - covered by our extensibility solutions
• Maintainability - covered by our extensbility solutions
• Modularity - as shown in the data flow, the sytem design is already quite modular in its pulls from external data sources and this is one of the reasons we would be able to replace and add functionaltiies
• Reliability - since our score is being generated by our scoring engine (where the logic is outside the scope of the project), it should consistently return the same score given the same criteria and properties
• Security - as mentioned in the project proposal, it’s assumed that the application will be “secure enough” and since we aren’t storing any user data this attribute isn’t a priority
• Testibility - since each score generated would be unqiue to the user’s preferences and available properties, these would be subjective and difficult to test

Evaluation

Achieving the functionality -

The project will be deemed functional if:

• the first page of the application asks the user for a location and gives them the option of choosing between 1-10 for each of the 10 criteria based on their priority
• the next page displays a interactive map or list of properties, each with a score generated by the scoring engine that has been passed all of the user preferences
• on that page, users can select two properties to view the photos and description side by side
• users can click the property and be given the option to be redirected to the original posting, for example on domain.com.au
• users have been given the option to go back to the previous page to change their inputs

For the user-facing components (though subjective), it should be noted that the system should try to be intuitive to navigate through and easy to follow.

Achieving the quality attributes -

The project will have achieved the quality attributes if:

• it can support 1000 users with a response time less than 1 second
• it can support 100 requests per second with less than 2% error rate
• have a greater than 99% success rate for API calls
• have new houses displayed less than 10 minutes after they are published
• it would take less than 100 lines of code to modify for replacing a data source
• take less than 8 hours to add another criteria into the scoring engine