ホテルの客室検索APIのアーキテクチャ設計時に考えたこと
作ったもののイメージ ホテルの客室検索APIとは、チェックイン日やその他の条件を入力として受け取り、マッチするホテルの客室を返すものです。以下の画像はExpediaのものですが、赤枠で囲っている部分（他にもたくさんある）が入力になります。2022年4月頃に無事リリースされました。 この検索APIを構築を任された際に、何を考えて設計していったのかを以下に示していきます。 顧客からの要望 顧客の会社は当時エンジニアがおらず（やりとりしている社長は元エンジニアだが）、これまでも私と仕事をしたことがあったので依頼が来ました。顧客と密にコミュニケーションを取りわかったのは、以下のような要望でした。 このAPIは自社サービスとして第3者（要契約）に使ってもらえるようにしたい 完全に一般公開ではなくちゃんと契約を結ばないと利用できないようなもの 検索条件を柔軟に、かつ使いやすい感じで指定できるようにした
AWSのサービスクォータをなめてると痛い目に遭うぞ！（全サービスクォータ一覧化スクリプト付き） - Qiita
はじめに AWSのサービスクォータ、意識していますか？ 小規模なシステムであれば、意識していなくても問題になることはないかもしれません。 しかし、大規模なシステムではアーキテクチャ設計からサービスクォータを意識していないと痛い目に遭うことがあります。 本記事では、サービスクォータを意識する必要性を解説します。 合わせて、全サービスクォータを一覧化するCLIスクリプトも紹介します。 2022/02/28 追記 続編書きました。↓ サービスクォータとは？ 一言で言えば**「AWSのサービス毎に定められた制限」**です。 以下はVPCのクォータです。 「リージョンあたりの VPC の数」はデフォルトで「5」となっています。 「デフォルトで」というのは調整できる＝引き上げ可能ということです。 なぜ、サービスクォータを意識しないといけないのか？ 結論から言うと、サービスクォータを意識していないと、シ
idをautoincrementして何が悪いの？
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで
マイクロサービス設計原則: SOLIDではなくIDEALS
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由｜ハイクラス転職・求人情報サイト AMBI（アンビ）
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
2018年11月2日に行われたAWS Dev Day Tokyo 2018での講演「マイクロサービス化デザインパターン」の資料です。Read less
新規Androidアプリ開発において何より大切なこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は Android Advent Calendar 2017 7日目の記事です。 当初は設計の話を書くつもりだったのですが、 明日のShibuya.apkで話すネタに困ったので使い回しの効く話題にしたかった その設計が期待通りのものになっているかどうかの検証ができていないので、開発全般のお話になりました。 設計の話題についてはまたどこかでお話できるかなと思います。 以下、エモい話です。 対象読者 この記事は以下のような方を対象として書いている…つもりです。 職業Androidエンジニア 自社サービスの開発に携わっている、またはア
京都市が今回失敗したような、自治体のシステム更新について
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/ Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？ A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。 それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。 Q2.なんで新規で作らないの？ A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。 Q3.メインフレーム（汎用機）って何？ A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーご
サーバーサイドレンダリング不要論 - Qiita
サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け
実録!!データ構造リファクタリング -- 僕とメッセージ機能の300日戦争 - Qiita
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の
wip: 個人開発でやる気枯渇を防ぐために気をつけてること、やってること - wadackel.me
現在趣味で Web サービスを作っています。今年の 4 月末くらいから準備をし始めていたので、かれこれ 4 ヶ月くらい開発を進めています。一人きりの開発+完成したとしても実際に使ってくれる人がどのくらいいるか分からないという状況ですが、なんだかんだ楽しみながら作業できています。 まだ完成もしていないので、こんな事を書くのは的外れのような気がしますが、やる気の枯渇を防ぐために自分なりに気をつけていること+やっていることを書き出しました。既に色々な方が書いているような内容なのであまり目新しいものでは無いかもしれません、あくまでも僕なりの内容となっています。 自分が使いたいものを作る 凄い基本的なことですが、凄く大事なことのように思います。今作っているのが、主に Web サイトのデザインをアーカイブしておくための(Pinterest みたいな)サービスなのですが、少し前から欲しい欲しいと思ってい
Amazon.comがモノリシックな構造からSOAへ移行したときに気がついた間違い。同社CTOが語る
ニューヨークで開催されたイベント「AWS Summit 2016 New York」。基調講演で同社CTOのWerner Vogels氏は、Amazon.comのシステムがモノリシックな構造からSOAへ、そしてマイクロサービスへ移行する際に得た教訓について手短に紹介しています。 機能ドリブンでサービスを分解するべきだった Werner Vogels氏。 10年前の話をしよう、Amazon.comは巨大なモノリシックな構造から転換してきた。私たちのお客様もおそらく、似たような経験をこれからするはずだ。 Amazon.comは、モノリシックな構造からSOAに転換すると決めた、それはいわゆるSOAが登場するよりも前の時期だ。 さまざまなコンポーネントをサービス化し、APIでつなげるようにした。これは非常にうまくいったが、しかし私たちは間違いにも気づき始めていた。 それは、データドリブンにサービス
ひとりぼっちのサービス開発における技術選択の遷移と戦略 - Qiita
by @appwatcher 以前下記で書かせていただいた goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 ですが、上から下まですべてを担当して個々の技術をすべてやった経験自体も勉強になったのですが、 どうして、そのような技術選択をしたか？という点が自分でも振り返ってみて学ぶ点がありました。 それぞれ良し悪しがあったので何かしらの参考になればと思い、それ以後の技術変遷や取捨選択を踏まえて、振り返ってみたいと思います。 なにかしらの参考になれば。 ちなみに未だに一人です。 今回の技術選択をした時の基準や自分なりの戦略 スピード重視。これは今回に限らず自分自身の戦略です。基本通常の人の３倍のスピードでやる気概でやってます。 ユーザーグロース重視。これはサービス立ち上げからやるので当然。 コスト重視。今回フリーになってコストまできちんと意識するようにな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
[社内勉強会]ELBとALBと数万スパイク負荷テスト![[社内勉強会]ELBとALBと数万スパイク負荷テスト](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d66722d28b188f243f0cd881f7598f699791ab1/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Felbalb-160822022623-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)