Get a quote

System Architecture · Sariyer

System Architecture for Sariyer businesses

Add a trim level and the places needing an update scatter: the price list sits somewhere, the image folder somewhere else, the campaign note somewhere else again. Whichever one lags, a customer is the first to notice. Along the Maslak plaza line in Sariyer, a product that multiplies through trim and colour options multiplies the places needing an update with it. On the KGM SsangYong sales channel a trim and colour pairing is a record in its own right, holding its price, its image and its sale terms on one row.

System Architecture — Sariyer

Sariyer's fabric leans on technology and head office towers and on the university campus edge around Ayazaga; what they share is a product that multiplies through options. Where the channel does not reach belongs in writing: the KGM SsangYong sales channel was built for automotive retail, so a technology office's own release and issue tracking is not in it, and for a banking or investment product we have nothing to show. What carries over is where a choice becomes a record. Configurator and payment are two steps of one flow, and the pairing a visitor assembles moves into the next step as a record. The channel runs on the same Laravel, MySQL and Redis set as the brand's corporate site, with Tailwind and jQuery on the interface.

  • A trim and colour pairing is a record of its own, holding price, image and sale terms on one row, so separately maintained lists cannot drift apart from each other.
  • Configurator and payment are two steps of one flow: the configuration a visitor assembles moves forward as a record, so nothing has to be entered a second time.
  • The sales channel runs on the same Laravel, MySQL and Redis set as the brand's corporate site, which keeps both systems inside one area of competence to maintain.

Why Algoriel

  • The parts read one source

    At Tahlil.com the site, the admin panel and the mobile app read the same information instead of behaving as three systems.

  • Where each job is solved comes first

    Which layer handles which job is decided before code, because work that has to move later is expensive to move.

  • The summary recomputes itself

    As the Günlük Hava Durumu archive grows, the climate summary recomputes from it; nobody maintains a monthly table by hand.

  • One rule for file layout

    On the KGM SsangYong site, where a file is written and under what name now follows one rule the upload code obeys.

  • Where the data divides

    When several institutions share one system, each enters through its own domain and student, guardian and payment records stay inside that institution's boundary. This arrangement is what the term multi-tenant describes.

  • What a record attaches to

    Whether service history is written against a person, an address or a device is settled before the schema exists. Reversing that later means re-attaching everything already recorded.

  • Permission held in the data model

    A teacher, a guardian and an institution administrator reach the same timetable record at their own level of access. Permission is part of how the record is defined, not a view switched off on a screen.

  • Splitting the read path

    Which screens are served from a held copy and which go to the database is settled before the first record exists. On Vipkurum a frequently opened screen comes from the copy, and only a read with no copy reaches the database.

  • Interfaces on a single system

    Tahlil.com hangs three interfaces off one system: the patient site, the physician panel and the mobile app read the same record, and no second data model is written per interface.

  • Storage laid out on day one

    The naming and folder scheme files will live under is fixed at the start; a layout imposed afterwards turns into a migration.

Work like this

System Architecture · Case study

KGM SsangYong Online Store — a pairing carries its own price, image and terms

Built for automotive retail, the channel carries a buyer from presentation to payment in one flow. The decision is held by a record, not a document: every trim and colour pairing is written down with a price, an image and sale terms of its own. The record forms as the visitor works through the options, and the car on screen moves with the figure beside it. Payment is not a separate system but the next step of the same flow, inheriting the record the visitor assembled. Maintenance took one decision too: the channel shares a single Laravel, MySQL and Redis set with the corporate site, with Tailwind and jQuery on the interface.

Read the case study →

Working with Sariyer teams, remotely

We have no office, so work for this city runs remotely and we do not offer on-site support. What was done, and why it was done that way, stays in writing. The project pages mark which builds came out of a partnership.

  • The first release ships as a working piece; extras follow later.
  • Every client we know of is in Turkey.
  • Decisions stay in writing; progress shows in working screens.

Frequently asked

  • Could we not keep the price list in a separate sheet?

    You could, but once price, image and sale terms live in separate places one of them always lags, and a customer sees the gap on screen. When the pairing is its own record, the only thing being updated is that record.

  • What if we build the configurator and the payment step as two systems?

    That works, and the cost shows up in the handover: the configuration is created in one place, the order in another, and a matching step opens between them. Here the payment step opens inside the same flow and takes over the configuration record as it stands.

  • Would separate stacks for the corporate site and the sales channel not be more flexible?

    The flexibility stays on paper while the maintenance doubles. The channel and the corporate site sit on the same Laravel, MySQL and Redis set, so releases, security patches and debugging gather in one area of competence.

  • We are a finance team. What does this evidence say to us?

    For a banking or investment product we have nothing to show, and we promise nothing there. What we are describing is how to shape the record for a product that multiplies through options. We keep no office, the decision arrives as a written output, and a message from the form gets an answer within 2 working days.

Let us settle where your data divides before any code is written.