Task 6 — Hardware Store Search Engine

Objective

Create a hardware-store marketplace and search engine.

The system contains three markets.

Each market contains hardware components divided into sectors.

Markets may contain the same component with:

different price
different stock availability

The application must load the complete hardware database from a file, parse each component into the correct model, and provide search, comparison, purchase, configuration, and stock-update operations.

Hardware Sectors

The supported sectors are:

CPU
Motherboard
GPU
RAM
PowerSupply
PcCase
Cooler
SSD

Each sector has its own component attributes.

Do not model every hardware component as one large structure containing unrelated optional fields.

Each component type should preserve its own domain-specific attributes.

Common Market Information

Every sellable item contains at minimum:

Component ID
Price
Stock
Market ID

These values can be represented using a shared model or interface when useful.

CPU

CPU data contains:

ID
Maker
Chip Socket
Generation
Chip Model
Chip Version
Core Count
Base Frequency
Turbo Frequency
Price
Stock

A possible model is:

type CPU struct {
    ID             int
    Maker          string
    ChipSocket     string
    Generation     int
    ChipModel      string
    ChipVersion    string
    Cores          int
    BaseFrequency  float64
    TurboFrequency float64
    Price          float64
    Stock          int
}

Examples from the supplied database include:

Intel i5 11600
Intel i7 12700K
Intel i9 12900K
AMD Ryzen 7 5700X
AMD Ryzen 9 5950X
AMD Ryzen 9 7950X

Motherboard

Motherboard data contains:

ID
Maker
Processor Platform
Chip Socket
Model
RAM Version
M.2 Slot Count
Price
Stock

A possible model is:

type Motherboard struct {
    ID        int
    Maker     string
    Processor string
    ChipSocket string
    Model      string
    RAMVersion string
    M2Slots    int
    Price      float64
    Stock      int
}

GPU

GPU data contains:

ID
Manufacturer
Maker
Model
RAM
Price
Stock

A possible model is:

type GPU struct {
    ID           int
    Manufacturer string
    Maker        string
    Model        string
    RAM          int
    Price        float64
    Stock        int
}

RAM

RAM data contains:

ID
Manufacturer
Model
RAM Version
Capacity
Frequency
CL
Price
Stock

For example:

type RAM struct {
    ID           int
    Manufacturer string
    Model        string
    RAMVersion   string
    CapacityGB   int
    FrequencyMHz int
    CL           int
    Price        float64
    Stock        int
}

Power Supply

Power-supply data contains:

ID
Manufacturer
Model
Capacity
Price
Stock

For example:

type PowerSupply struct {
    ID           int
    Manufacturer string
    Model        string
    CapacityW    int
    Price        float64
    Stock        int
}

PC Case

PC-case data contains:

ID
Manufacturer
Model
Front Panel Support
Top Panel Support
Price
Stock

A possible model is:

type PcCase struct {
    ID           int
    Manufacturer string
    Model        string
    FrontPanel   string
    TopPanel     string
    Price        float64
    Stock        int
}

Cooler

Cooler data contains:

ID
Manufacturer
Model
Size
Socket Support
Price
Stock

A possible model is:

type Cooler struct {
    ID            int
    Manufacturer  string
    Model         string
    Size          string
    SocketSupport []string
    Price         float64
    Stock         int
}

The raw source uses values such as:

1200-AM4
1200-1700-AM4
1200-1700-AM4-AM5

These may be parsed into a collection of supported sockets.

SSD

SSD data contains:

ID
Manufacturer
Model
Size
PCI Support
Price
Stock

A possible model is:

type SSD struct {
    ID           int
    Manufacturer string
    Model        string
    Size         string
    PCISupport   float64
    Price        float64
    Stock        int
}

Source Data

The original task provides complete component tables for three markets.

The supplied database must be copied into a single input file.

The application must then:

read the file
detect market sections
detect component sectors
parse each row
create the correct component structure
preserve market-specific price and stock

The same component ID may exist in multiple markets.

Therefore:

Component ID alone is not a globally unique inventory key.

Inventory identity should include at least:

Market ID
Component Type
Component ID

Market Model

A possible structure is:

type HardwareMarket struct {
    ID           int
    CPUs         []CPU
    Motherboards []Motherboard
    GPUs         []GPU
    RAM          []RAM
    PowerSupplies []PowerSupply
    Cases        []PcCase
    Coolers      []Cooler
    SSDs         []SSD
}

Other designs are valid as long as component-specific attributes remain strongly modeled.

Search Engine

Create a search engine capable of:

searching
comparing
suggesting
purchasing
building complete configurations
updating stock

A useful conceptual separation is:

        Catalog
           |
        Search Engine
           |
           +-- Search
           +-- Compare
           +-- Suggest
           +-- Purchase
           +-- Build Configuration

Stock mutation should happen only during purchase or delivery operations.

Required Queries

Query 1 — Alex

Alex wants to buy a motherboard with:

Socket = 1700
Price >= 300
Price <= 400

The result must consider all markets and only available components.

Query 2 — Ben

Ben wants information about the best price for:

CPU Maker = Intel
Generation = 12
Cores = 12

This is an information query.

It should locate matching CPUs and identify the best available price.

Query 3 — Cane

Cane wants information about the difference between:

Intel
Generation = 12
Cores = 16

and:

AMD
Series = 5000
Cores = 16

The comparison should return the relevant component data rather than only a boolean result.

Useful comparison fields include the attributes present in the CPU models, such as:

model
generation
socket
cores
base frequency
turbo frequency
price
stock

Query 4 — Diana

Diana wants information about AMD 7000-series CPUs with:

8 cores
12 cores
16 cores

The search should return matching processors for all requested core counts.

Query 5 — David

David wants to buy:

Intel 12900K
AMD 5950X
AMD 7950X

Each component must be located in available market stock.

A successful purchase must decrease the corresponding market inventory.

Query 6 — Elena

Elena wants information about all motherboards where:

Model contains Z690
Price >= 400
Price <= 450

This is an information query.

No stock should be modified.

Query 7 — Fred

Fred wants to buy:

Motherboard platform = AMD
Socket = AM4
Quantity = 2
Selection = cheapest valid motherboard

The selected market must contain at least two units.

The search must compare prices across markets before purchasing.

Query 8 — Gina

Gina wants to buy the most expensive ASUS motherboard satisfying:

Socket = AM5
RAM Version = DDR5
M.2 Slots = 4
Manufacturer = ASUS
Selection = most expensive

The component must be in stock.

Query 9 — Helen

Helen wants information about all motherboards satisfying:

Processor = AMD
RAM Version = DDR4
M.2 Slots = 2
Price >= 200
Price <= 250

This is an information query.

Query 10 — Kyle

Kyle wants to buy the most expensive motherboard compatible with:

Intel i9 12900K

The implementation must first derive the CPU compatibility requirements and then find a compatible motherboard.

At minimum, the motherboard socket must match the CPU socket.

The source data provides:

Intel i9 12900K
Socket = 1700

The query must not simply search for a hard-coded motherboard ID.

Query 11 — Paul

Paul wants to buy two coolers for an:

NZXT H7 PC case

Requirements:

Mount position = top panel
CPU support = Intel i9 12900K
Price >= 220
Price <= 250
Quantity = 2

This requires combining data from:

PcCase
CPU
Cooler

The selected cooler must:

fit the case’s top-panel support
support the CPU socket
satisfy the price range
have sufficient stock

Query 12 — Lara

Lara wants to buy RAM for two configurations.

DDR4 Requirement

4 RAM slots
DDR4
3600 MHz
CL-16

DDR5 Requirement

4 RAM slots
DDR5
6400 MHz
CL-32

The source wording uses:

4 RAM slots

while the RAM records themselves describe module or kit capacity rather than motherboard slot count.

The implementation should not silently reinterpret this requirement.

A reasonable interpretation is that Lara requires four RAM units or modules matching each specification, but this interpretation must be documented if used.

Query 13 — Tina

Tina wants:

KINGSTON 500GB M.2 SSD — quantity 2
SAMSUNG 500GB M.2 SSD  — quantity 2

Behavior:

if both are available:
    buy both

if only one type is available:
    buy the available type anyway

This is an explicit partial-purchase case.

Query 14 — Victor

Victor wants a complete PC configuration.

Requirements:

CPU
AMD 7950X

Motherboard
most expensive motherboard compatible with the CPU

GPU
AMD RX6600 XT
8 GB RAM

RAM
DDR5
6400 MHz
CL-32

Power Supply
CHIEFTEC
850 W
Price between 150 and 200

PC Case
NZXT
Front panel supports 3x120mm
Top panel supports 3x120mm
Price between 200 and 250

Cooler
CORSAIR
supports AMD 7950X
3x120mm

SSD
three M.2 SSDs
1 TB each
PCI 4.0

The search engine must resolve the complete configuration using market inventory.

Configuration Compatibility

For Victor’s configuration, the implementation must check compatibility where the supplied data supports it.

Examples include:

CPU socket <-> motherboard socket
CPU socket <-> cooler socket support
Motherboard RAM version <-> RAM version

Do not invent compatibility properties that do not exist in the source data.

For example, the provided case data does not define GPU length, so GPU-case length compatibility cannot be validated from the supplied dataset.

Multi-Market Configuration

The source does not state that the complete PC configuration must come from one market.

Therefore the implementation must document whether:

all components must come from one market

or:

each component may be selected from the best available market

Do not silently assume one interpretation.

Delivery Processing

Simon represents delivery support.

Delivery operations add stock to existing market items.

A delivery contains:

Market ID
Item Type
Item ID
New Delivery Quantity

A possible model is:

type Delivery struct {
    MarketID int
    ItemType string
    ItemID   int
    Quantity int
}

Market 1 Deliveries

Apply:

CPU|10|2
CPU|20|3

Motherboard|8|3
Motherboard|16|2
Motherboard|21|1

GPU|5|3
GPU|7|2
GPU|10|2

RAM|8|8
RAM|10|8
RAM|12|8

PowerSupply|7|4
PowerSupply|9|6

PcCase|4|6
PcCase|6|4

Cooler|5|3
Cooler|7|3

SSD|5|4
SSD|9|4

Market 2 Deliveries

Apply:

CPU|9|2
CPU|18|3

Motherboard|7|3
Motherboard|15|2
Motherboard|20|1

GPU|4|3
GPU|6|2
GPU|9|2

RAM|7|8
RAM|9|8
RAM|11|8

PowerSupply|8|6
PowerSupply|10|4

PcCase|3|6
PcCase|5|4

Cooler|4|3
Cooler|6|3

SSD|6|4
SSD|8|4

Delivery Update

For:

Current Stock = S
Delivery = D

calculate:

New Stock = S + D

The update must target exactly:

Market ID
Component Type
Component ID

For example:

Market 1
CPU
ID 10
+2

must not update CPU ID 10 in Market 2 or Market 3.

Unknown Delivery Item

If a delivery references an item that does not exist in the specified market, report an error.

Do not silently create a new hardware model from incomplete delivery data.

Purchase Processing

A successful purchase must decrease stock.

For:

Current Stock = S
Purchased Quantity = Q

calculate:

New Stock = S - Q

only when:

S >= Q

Stock must never become negative.

Information Queries

Queries asking only for information must not change stock.

Examples include:

Ben
Cane
Diana
Elena
Helen

Purchase Queries

Purchase-oriented queries include:

Alex
David
Fred
Gina
Kyle
Paul
Lara
Tina
Victor

where applicable according to the specific request.

Search Result

A generic result should preserve both the hardware component and the market where it was found.

For example:

type MarketItem[T any] struct {
    MarketID int
    Item     T
}

or an equivalent language-specific design.

Purchase Result

A purchase result may contain:

type PurchaseResult struct {
    Buyer      string
    MarketID   int
    ItemType   string
    ItemID     int
    Quantity   int
    UnitPrice  float64
    FinalPrice float64
    RemainingStock int
}

Multi-component purchases should return multiple item results.

Validation

The parser and processing layer should validate:

known market IDs
known component types
valid component IDs
price >= 0
stock >= 0
purchase quantity > 0
delivery quantity > 0
valid numeric fields
required model attributes

Source Data Notes

The supplied hardware database contains several values worth handling carefully.

For example, a GPU entry in Market 2 contains:

Price = 0

and another GPU entry in Market 3 also contains:

Price = 0

The source does not explain whether zero means:

free
missing price
invalid data

The implementation should not silently reinterpret zero.

It should either:

preserve the source value and define how search handles it
or report it as invalid market data

The chosen behavior must be documented.

Required Tests

Create at least one test for every query type executed by the search engine.

This requirement applies to all supported query forms.

Examples include tests for:

price-range search
cheapest selection
most-expensive selection
component comparison
direct purchase
multi-item purchase
partial purchase
compatibility search
complete configuration search
delivery update

A single test should verify one clearly defined processing behavior.

Requirements

The implementation must:

model every hardware sector
preserve component-specific attributes
load the complete provided database from a file
parse all three markets
preserve market-specific price and stock
search across markets
support information queries
support purchases
support price-range filtering
support cheapest-item selection
support most-expensive-item selection
support component comparison
support compatibility-based searches
support direct multi-item purchase
support partial purchases where explicitly requested
build a complete PC configuration
update stock after purchases
process delivery updates
prevent negative inventory
report missing components
keep information queries free of side effects
create at least one test for every executed query type

Modeling Goal

This task should not become one massive function.

A useful conceptual architecture is:

        Raw Hardware Database
                |
                v
              Parser
                |
                v
        Hardware Markets
                |
                +-----------------------+
                |                       |
                v                       v
          Search Engine          Inventory Service
                |                       |
                +-- Find                +-- Purchase
                +-- Filter              +-- Delivery
                +-- Compare             +-- Stock Update
                +-- Suggest
                +-- Compatibility
                |
                v
        Configuration Builder

The key challenge is not only filtering lists.

The implementation must model several different hardware domains, preserve independent market inventory, and combine search results to answer higher-level requests.

Keyboard shortcuts

Scalionix Programming Task Library [ v1.0.0 ]