---
title: "Projektowanie systemów i architektura"
description: "Decyzje, które później drogo zmieniać: granice usług, przepływ danych, wybór platform i scenariusze awarii, których nikt nie wycenił."
language: "pl"
canonical: "https://zapolu.com/pl/services/system-design/"
---

# Projektowanie systemów i architektura

Systemy rzadko zawodzą z powodu źle napisanej funkcji. Zawodzą przez
decyzje podjęte miesiące wcześniej: gdzie przebiegają granice usług,
które dane są przechowywane w którym systemie, co się dzieje, kiedy
zależność ulegnie awarii. Na tablicy takie decyzje są tanie, na
produkcji drogie, więc właśnie w nie inwestujemy czas projektowy.

## Co projektujemy

- **Architektury commerce.** Storefront, backend i systemy
  towarzyszące: ERP, PIM, WMS, płatności, wyszukiwarka. Co kupić,
  co zbudować i gdzie powinny przebiegać granice między systemami.
- **Topologie integracji:** komunikacja zdarzeniowa kontra
  request-driven, kolejki i obsługa dead-letterów, idempotencja oraz
  to, co „eventually consistent” oznacza dla zamówienia, które musi
  zostać wysłane jutro.
- **Przepływ i własność danych.** Jedno źródło prawdy (system of
  record) na każdy fakt. Większość błędów integracyjnych, do których naprawiania nas
  wynajmowano, sprowadza się do tego, że cena ma naraz dwóch
  właścicieli.
- **Skalowalność i scenariusze awarii.** Profile obciążenia pod
  kampanijne skoki, strategia cache, łagodna degradacja: kiedy
  silnik rekomendacji jest niedostępny, klient powinien zobaczyć
  nieco uboższą stronę, a nie błąd.
- **Ścieżki migracji.** Jak dojść od obecnej architektury do
  docelowej krokami, z których każdy przynosi wartość, zamiast
  dwuletniego przepisywania, z którego wartość pojawia się dopiero
  na samym końcu.

## Jak to dostarczamy

Praca architektoniczna jest częścią większości naszych zleceń, ale
wykonujemy ją też osobno: przegląd architektury, którą właśnie
zamierzasz przyjąć, spisana architektura docelowa z planem migracji
albo druga opinia, kiedy dwaj dostawcy proponują niezgodne ze sobą
kierunki rozwoju. Efektem jest zawsze dokument, który Twój zespół
może zrealizować bez nas.

## Na co optymalizujemy

Domyślnie wybieramy nudną technologię i najmniejszy system, który
spełnia wymagania, i projektujemy z założeniem, że zespół
utrzymujący system będzie mniejszy niż ten, który go zbudował.